[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: Mon, 3 Nov 2014 17:37:07 +1030
User-agent: Mutt/1.5.23 (2014-03-12)

On Fri, Oct 31, 2014 at 12:50:25PM -0700, Paul Eggert wrote:
> 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.

Really, it's a fiction that the size argument of obstack_blank_fast
has a type.  (This is what happens when you start being pedantic in
documentation. :-)  A worse pedant comes along and says you aren't
completely correct.)  Please don't take this as a challenge to make the
manual completely correct!  I think we'd make it unreadable it we did.
At least, I wasn't clever enough to write something that was simple
yet correct..

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

I've added: "Earlier
versions of obstacks allowed you to use @code{obstack_blank} to shrink
objects.  This will no longer work."

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

Yes, thanks!  I've added the bug number to the list fixed with 2.21
and stolen your wording for a NEWS item, minus the "(actually large
positive)" phrase.

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

There another gnulib issue too.  AC_FUNC_OBSTACK is no longer correct.
The system libc may support obstacks, but not the current version.  It
seems to me the easiest solution is to always include obstack.o in
libgnu.a.  If the system libc is up to date, then obstack.o will be

And another small tweak: Don't use alignof.h if __IBM__ALIGNOF__ is
defined (alignof.h just uses __alignof__ in that case), or when
__alignof__ is defined (for oddball systems, or testing).

Alan Modra
Australia Development Lab, IBM

Attachment: 0001-obstack-macro-return-values-and-always-add-obstack.o.patch
Description: Text Data

reply via email to

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