Re: [PATCH 0/5] obstacks again

[Gary V. Vaughan]

On Dec 5, 2014, at 7:13 PM, Eric Blake <address@hidden> 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)