[0/5] obstacks again

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 
@code{-@var{S}} 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.

On 10/31/2014 01:50 PM, Paul Eggert wrote:
> 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
> @code{-@var{S}} 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.

Can we use ssize_t instead of size_t for obstack_blank_fast?

Eric Blake wrote:
> Can we use ssize_t instead of size_t for obstack_blank_fast?

Not portably, no.  ssize_t need not be the same width as size_t.

As I understand it, ssize_t was partly invented to support platforms where 
'read' took a 64-bit size_t argument and returned a 32-bit signed result -- and 
ssize_t is therefore best avoided except when dealing directly with system calls 
that return ssize_t.