This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/5] obstacks again
- From: "Gary V. Vaughan" <gary at gnu dot org>
- To: Eric Blake <eblake at redhat dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, Alan Modra <amodra at gmail dot com>, libc-alpha at sourceware dot org, bug-gnulib at gnu dot org
- Date: Fri, 5 Dec 2014 21:02:46 +0000
- 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>
On Dec 5, 2014, at 7:13 PM, Eric Blake <eblake@redhat.com> wrote:
> On 10/29/2014 09:35 PM, Paul Eggert wrote:
>> Alan Modra wrote:
>>
>>> One thing though, I didn't put the ChangeLog diffs in the patch as I
>>> usually add them when committing.
>>
>> Oh, I missed that. I added them now. For Gnulib it's better to put
>> them into the patch.
>>
>>> It is no longer possible to shrink an obstack with obstack_blank (but
>>> you can still do that with obstack_blank_fast).
>>
>> Ouch, I hadn't noticed that. That's an incompatible change and I expect
>> it will break real-world usage for no particularly good reason, so we
>> really need to fix this. How about making the 2nd argument to
>> obstack_blank and obstack_blank_fast be of type ptrdiff_t rather than
>> size_t?
>
> It breaks GNU M4, for a starter :) But at least we predicted that it
> would happen, and I'm hoping the fallback of obstack_blank_fast does the
> job.
It does, thanks.
Although for someone not following bug-gnulib fairly carefully, it is far
from obvious why bumping gnulib makes your application suddenly use up all
the available memory. Which is a shame, because, other than that M4 would
have been perfectly functional after the gnulib bump without any special
client code changes.
If there's a way to at least diagnose negative arguments rather than silently
change behavior, that would save other projects some migration headaches...
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)