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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 26 Apr 2015 06:50:33 -0700
- 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> <54E27473 dot 6030407 at cs dot ucla dot edu> <54E46D70 dot 7000601 at redhat dot com> <553A6311 dot 70407 at redhat dot com>
On Fri, Apr 24, 2015 at 8:36 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 02/18/2015 11:46 AM, Florian Weimer wrote:
>> On 02/16/2015 11:51 PM, Paul Eggert wrote:
>>> 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,
>>
>> Indeed. I introduced __tzstring_len to avoid the need for the copy, and
>> broke down __tzset_parse_tz into several smaller functions. Hopefully,
>> the control flow is more transparent.
>
> I've committed this now, with a few whitespace fixes.
>
This caused:
https://sourceware.org/bugzilla/show_bug.cgi?id=18333
--
H.J.