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