This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/5] obstacks again
- From: Alan Modra <amodra at gmail dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: libc-alpha at sourceware dot org, bug-gnulib at gnu dot org
- Date: Thu, 30 Oct 2014 16:37:23 +1030
- Subject: Re: [PATCH 0/5] obstacks again
- Authentication-results: sourceware.org; auth=none
- References: <20141029033201 dot GI4267 at bubble dot grove dot modra dot org> <5450983F dot 3030608 at cs dot ucla dot edu> <20141029220223 dot GP4267 at bubble dot grove dot modra dot org> <5451B1F6 dot 7060305 at cs dot ucla dot edu>
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