[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/5] obstacks again

From: Paul Eggert
Subject: Re: [PATCH 0/5] obstacks again
Date: Fri, 31 Oct 2014 12:50:25 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

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

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.

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

reply via email to

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