This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v3] tzset robustness [BZ#17715]
- From: Florian Weimer <fweimer at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 16 Mar 2015 16:00:59 +0100
- 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> <54F6F8FC dot 6010903 at redhat dot com>
On 03/04/2015 01:22 PM, Florian Weimer 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.
> Should I split this up into multiple parts?
> One of the issues addressed was previously raised on oss-security:
Florian Weimer / Red Hat Product Security