Re: [PATCH v3] tzset robustness [BZ#17715]

[Paul Eggert <eggert at cs dot ucla dot edu>]

Florian Weimer wrote:
> So I'm not sure what to do here.  Get rid of the alloca?  That's going
> to be more difficult to review.

I haven't read the code carefully, but if the only reason for the alloca is to 
have a temporary string that one can munge by storing '\0' bytes at strategic 
locations, then I presume that one could rewrite the code to avoid the need to 
make a temporary copy, and that this would make the change harder to review. 
This may be the best we can do, though.

> I think TZNAME_MAX only applies to the âPSTâ part.

True, but I don't see how this contradicts what I wrote.

There are two limits here: the length limit for the entire TZ string (which 
POSIX does not allow a tight limit for), and the length limit for the time zone 
abbreviation (which is less than the TZ string limit, and which POSIX allows a 
tight limit for).  Currently glibc does not impose much of a limit on either 
quantity.  It sounds like you're thinking of limiting the latter to 255 bytes. 
If so, this new restriction should be done consistently and correctly, e.g., by 
altering how sysconf (_SC_TZNAME_MAX) behaves.

Currently neither glibc nor Solaris impose a tight limit on time zone 
abbreviation length, so this would be an incompatible change.  It probably 
wouldn't affect much real-world code, though.