This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] tzset robustness [BZ#17715]
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 16 Feb 2015 14:51:31 -0800
- Subject: Re: [PATCH v3] tzset robustness [BZ#17715]
- Authentication-results: sourceware.org; auth=none
- References: <54E24689 dot 4010108 at redhat dot com> <54E24EEF dot 6090503 at cs dot ucla dot edu> <54E2516E dot 8050100 at redhat dot com>
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.