This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/5] obstacks again
- From: Alan Modra <amodra at gmail dot com>
- To: "Gary V. Vaughan" <gary at gnu dot org>
- Cc: Eric Blake <eblake at redhat dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org, bug-gnulib at gnu dot org
- Date: Sat, 6 Dec 2014 12:19:44 +1030
- Subject: Re: [PATCH 0/5] obstacks again
- Authentication-results: sourceware.org; auth=none
- References: <20141029033201 dot GI4267 at bubble dot grove dot modra dot org> <5450983F dot 3030608 at cs dot ucla dot edu> <20141029220223 dot GP4267 at bubble dot grove dot modra dot org> <5451B1F6 dot 7060305 at cs dot ucla dot edu> <548203C3 dot 6040601 at redhat dot com> <6D396292-DE8A-4632-9EBA-AE7C58E0BC41 at gnu dot org>
On Fri, Dec 05, 2014 at 09:02:46PM +0000, Gary V. Vaughan wrote:
> If there's a way to at least diagnose negative arguments rather than silently
> change behavior, that would save other projects some migration headaches...
We could diagnose one of the m4 uses of obstack_blank at compile time,
but not the one in m4/macro.c:trace_flush which has a non-constant
shrink value..
Yes, I agree this can cause some pain, but at least dying with
out-of-memory is a loud symptom.
The alternative is to do as Paul suggested and make obstack_blank
accept a negative length argument, but that would
- kill >2G obstacks on 32-bit targets,
- lose the nice symmetry with other obstack functions,
and obstack_blank_fast is the right interface to use for shrinking.
--
Alan Modra
Australia Development Lab, IBM