Re: [PATCH 0/5] obstacks again

[Paul Eggert]

On 10/29/2014 11:07 PM, Alan Modra wrote:
> So there are my reasons for leaving obstack_blank as is.

Thanks, they're persuasive.  With that in mind, I have a minor complaint 
about obstack_blank_fast's revised documentation.  It says "You can use 
@code{obstack_blank_fast} with a negative size argument to make the 
current object smaller."  Technically, though, the argument is of type 
size_t so it cannot be negative.  So, how about if we change this 
wording to "If @var{S} is a positive size, you can give 
@code{obstack_blank_fast} a ``negated'' (actually, large positive) size 
@address@hidden to shrink the current object by @var{S} bytes."  Also, 
it may be worth noting explicitly that this trick does not work for 
object_blank.

Also, doesn't libc need a NEWS item for these changes?  At least, gnulib 
needs one; I installed the attached.

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

Yes, that makes sense.  Don't we have similar problems with lots of 
other macros and/or functions: obstack_1grow_fast, obstack_blank_fast, 
obstack_int_grow, etc.?  They all seem to return types that don't match 
the documentation.  As long as we're fixing things, this might all be 
done in a separate patch.

> It's missing @safety markup for the
> previously undocumented obstack_begin, obstack_specify_allocation, and
> obstack_specify_allocation_with_arg macros.  I'm hoping someone else
> can do that as I'd just be guessing.  (Are they even appropriate for
> macros?)

Sorry, I don't know.

If I understand the recent set of proposed patches correctly, no further 
changes need to be made to gnulib, unless we decide to go ahead with the 
further "breakage" mentioned above.

0001-obstack-add-NEWS-entry-for-recent-incompatible-chang.patch
Description: Text Data