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: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 04 Mar 2015 13:22:20 +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>
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