This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]