[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