[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: Tue, 04 Nov 2014 00:43:05 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 11/02/2014 11:07 PM, Alan Modra wrote:
Really, it's a fiction that the size argument of obstack_blank_fast has a type.

Yes and no. It's a fiction in the sense that obstack_blank_fast is a macro, so its argument doesn't actually have a C type. But it's not a fiction in the sense that obstack_blank_fast can be documented as if it were a function, and if a program calls it with valid arguments that a function would have, it behaves like that function.

In this sense, obstack_blank_fast is like putchar. Although putchar is a macro and strictly speaking its argument doesn't have a C type, it is documented to take a value of type int, and if you call it according to its specification it behaves properly.

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

But this doesn't suffice for obstack_blank_stack, which *can* shrink objects and where user code relies on this feature. E.g., the following code (taken from GCC's finish_regexp_representation) should work if the current object size fits into 'int', and should continue to work if we change its 'int' to 'size_t' and allocate objects larger than what 'int' can represent:

   int length = obstack_object_size (&irp);
   obstack_blank_fast (&irp, -length);

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.

Thanks, I wrote a "harder" solution, which builds obstack.o only if the system version doesn't work with arbitrary size_t values. This is always true now but won't be once these fixes make their way into glibc.

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

I'd rather insulate obstack from that internal detail of alignof. I gave a shot at doing this in a different way, which preserves the insulation better.

A couple more things. obstack_chunkfun and obstack_freefun should also return void. And the code should avoid casting function values from one calling convention to another: this sort-of-works with the old API on glibc's current platforms but is likely to cause problems with the transition to the new one.

I installed the attached patches to gnulib to try to implement the above; please let me know of any issues.

Attachment: 0001-obstack-port-to-platforms-that-define-__alignof__.patch
Description: Text document

Attachment: 0002-obstack-do-not-assume-system-supplied-obstack-is-siz.patch
Description: Text document

Attachment: 0003-obstack-fix-macro-return-values.patch
Description: Text document

Attachment: 0004-obstack-avoid-potentially-nonportable-function-casts.patch
Description: Text document

reply via email to

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