[Top][All Lists]

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

Re: [PATCH 0/5] obstacks again

From: Alan Modra
Subject: Re: [PATCH 0/5] obstacks again
Date: Thu, 30 Oct 2014 16:37:23 +1030
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Oct 29, 2014 at 08:35:18PM -0700, Paul Eggert wrote:
> Alan Modra wrote:
> >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?

We could, but..  I expect there is going to be other downstream code
breakage anyway.  Witness the patches needed to make gcc work with a
more modern obstack.h, where a seemingly innocuous change like casting
the obstack_base value to void* broke code doing pointer arithmetic,
and gcc's use of the internal _obstack_begin function meant that gcc
was exposed to the changed chunkfun type.

Now if the 2nd arg of obstack_blank changes to type ptrdiff_t, then it
becomes an odd case, all the other obstack "functions" taking a size_t.
Also, I'd say obstack_blank is the wrong macro to use for shrinking,
the most natural one being obstack_blank_fast due to it bypassing the
obstack_room check.

So there are my reasons for leaving obstack_blank as is.  However, if
you and others prefer to go with ptrdiff_t I'm happy enough to submit
a patch.

Oh, and while I'm advocating breakage, the doc for obstack_next_free
says it returns a void* but actually returns a char*.  Since it was
deemed a good idea to similarly correct obstack_base, should we do the
same for obstack_next_free?

Alan Modra
Australia Development Lab, IBM

reply via email to

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