bug-gnulib
[Top][All Lists]
Advanced

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

[Bug-gnulib] Re: requirements of 'alloca' module


From: Simon Josefsson
Subject: [Bug-gnulib] Re: requirements of 'alloca' module
Date: Fri, 21 Nov 2003 06:25:15 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> alloca.c: depends on xmalloc, which I don't always want to use
>> (especially if just copy the file and use AC_FUNC_ALLOCA).
>
> Last week we encountered a new requirement about alloca(), namely that
> if you have a very strict notion of "safe", then alloca should only be
> used for amounts < 4 KB. This means we'll probably soon see a module
> 'safe-alloca' or so. But it will also use xmalloc. Or else, what would
> be your preferred way of indicating an allocation failure? Return NULL,
> like malloc() does?

The man page for BSD alloca, which I assume is what gnulib wants to be
compatible with, says the behaviour is undefined when there is no
memory left, and in practice I think the program abort.

I think the alloca gnulib module should do the same, e.g., use C
malloc and use abort if it fails.

Because this is unacceptable in a high-quality program, gnulib should
also provide another function, that behave the same as alloca, but
make it possible to do useful error handling.  This function should be
named something else, because it doesn't implement the same interface.

There seem to be two ways to implement "useful error handling".
Either return NULL when there is no memory (a'la C malloc), or use
xmalloc().  I think both are useful, I have some packages that handle
MALLOC failures that would prefer a NULL return value, and others that
don't want to mess with the details that would prefer the xmalloc
approach.

What do you think?

> Note that some gnulib code is already sensitive to "#define NO_XMALLOC".
> This is used to tell the code to behave like a library: return NULL or
> be silent about memory allocation errors, if appropriate, but don't call
> exit(). Is this something you would like to see applied to other gnulib
> modules? Or is all you need to set an 'xalloc_fail_func' that longjmps
> to somewhere?

Hm.  I think it depends on the module, and there are situations where
you want both approaches.  Here's an idea for solving this for a
hypothetical gnulib module 'foo'.  This reuses ideas from my response
to Paul, it might not make sense unless you have read those first.

1. foo.c is written using malloc.

2. gnulib-tool create Makefile rules for foo.o (like today) but also
   foo-xmalloc.o compiled with CFLAGS=-Dmalloc=xmalloc.

3. The gnulib m4 create @LTLIBOBJ@ definitions a'la @ALLOCA@ for @FOO@
   and @address@hidden  @FOO@ would go into @LTLIBOBJ@ unless the
   application explicitly wanted xmalloc, in which case @FOO_XMALLOC@
   would be used.

4. Application can use @LTLIBOBJ@ if it wants the defaults, or specify
   @FOO@ or @FOO_XMALLOC@ as appropriate.

This moves the clutter of selecting the malloc implementation into
configure.ac and Makefile.am instead of in C code.  Then in my C89
library I can add @FOO@ and in my command line application I can
specify @address@hidden

I admit this sounds complex, and that is usually bad.





reply via email to

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