[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] time: strftime_l: Use malloc rather than an unbounded alloca
From: |
Paul Eggert |
Subject: |
Re: [PATCH] time: strftime_l: Use malloc rather than an unbounded alloca. |
Date: |
Wed, 17 May 2023 10:40:05 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 |
On 2023-05-17 04:04, Adhemerval Zanella Netto wrote:
do you think it would be feasible to assume
_POSIX_TZNAME_MAX or 48 (for Factory zone) to avoid the malloc call on
strftime_l?
ALthough it's technically feasible, it'd be some work. Among other
things, whatever limit we chose would have to become visible via
<limits.h> and sysconf and etc., and we'd need to document that there is
now a limit. Better, I think, would be to continue to follow the GNU
coding standards and not impose an arbitrary limit on time zone
abbreviation length, even for the highly unusual case where code is
calling wcsftime or wcsftime_l.
How about avoiding the malloc in the following way? I installed the
attached patch into Gnulib lib/nstrftime.c, which has forked from glibc
but with some work could be merged back in, and this should also fix the
glibc bugs with buffer sizes exceeding INT_MAX.
If you don't want all the hassle of merging, you can cherry-pick this
patch. I haven't tested the patch, though, as Gnulib does not use this code.
0001-nstrftime-suggest-to-glibc-how-to-avoid-alloca.patch
Description: Text Data
- Re: [PATCH] time: strftime_l: Use malloc rather than an unbounded alloca.,
Paul Eggert <=