[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/5] obstacks again

From: Gary V. Vaughan
Subject: Re: [PATCH 0/5] obstacks again
Date: Fri, 5 Dec 2014 21:02:46 +0000

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...

Gary V. Vaughan (gary AT gnu DOT org)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]