This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix memory leak in printf_positional
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org
- Date: Fri, 28 Aug 2015 09:59:00 -0400
- Subject: Re: [PATCH] Fix memory leak in printf_positional
- Authentication-results: sourceware.org; auth=none
- References: <1440571295-20230-1-git-send-email-eggert at cs dot ucla dot edu> <alpine dot DEB dot 2 dot 10 dot 1508260930500 dot 26898 at digraph dot polyomino dot org dot uk> <55DFB7C7 dot 50307 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1508281350520 dot 5939 at digraph dot polyomino dot org dot uk>
On 08/28/2015 09:55 AM, Joseph Myers wrote:
> On Thu, 27 Aug 2015, Carlos O'Donell wrote:
>
>> I agree, but I don't think anyone should spend more than an hour trying
>> to find such a test case. The static analysis tools can show you a failure,
>
> I really don't think this case should take that long to find how to
> trigger the leak.
>
> There will of course be cases where the reason for no test case is
> something like "this bug only appears if you allocate memory occupying at
> least 3/4 of the address space, which is impossible on most current 64-bit
> systems and unreasonable for the testsuite to do on 32-bit systems even if
> possible" - or cases where it's unclear whether any combination of
> circumstances can cause the code in question to be reached in practice.
> But the starting point for most user-visible bug fixes should be that a
> test is added if it's straightforward to figure out how to test for the
> bug reliably within the context of the existing test infrastructure.
Agreed.
c.