Re: new module 'calloc-posix'

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bruno Haible on 9/2/2007 5:22 PM:
> Eric Blake wrote:
>>> I would somewhat like this idea - it is much nicer assuming that malloc
>>> reliably sets errno to ENOMEM on failure than having to patch all callers
>>> of malloc to do the same.
> 
> Jim Meyering confirmed:
>> Yes.  This is a fundamental goal of gnulib:
>> If there is some portability problem, don't penalize *all* software and
>> all systems.  Instead, keep the client software clean, and penalize
>> only the systems that have the problem.  The losing system (mingw,
>> in this case) can endure a little overhead in malloc/realloc wrappers.
> 
> Hmm, I was hesitating, because adding runtime overhead to _all_ malloc/realloc
> calls for the (rare) case of failure seems like overkill. But now I stumble
> on the need to set errno = ENOMEM even in totally unsuspected modules like
> 'xreadlink', so I come to agree that handling this in all callers is
> practically infeasible.

Who knows - maybe the mingw people will see this and fix their malloc as a
result of the overhead we impose on broken systems.

> 
> So I propose to add three modules 'malloc-posix', 'realloc-posix',
> 'calloc-posix' (using the '-posix' suffix that we already know from
> 'fnmatch-posix'/'fnmatch-gnu' and 'printf-posix').
> 
> Since 'calloc' is a little simpler to handle than 'malloc' and 'realloc',
> here is first a proposal for 'calloc'.

Comments below.

> 
> Also, I would propose to rename the modules 'malloc' -> 'malloc-gnu',
> 'realloc' -> 'realloc-gnu', 'calloc' -> 'calloc-gnu', similar to the naming
> of the fnmatch-* modules. (Only the modules. The file names and autoconf
> macro names can be left untouched.) Objections?

I guess the module rename would make it obvious to anyone using the old
'malloc' module that they now need to choose which semantics they want,
the simpler 'malloc-gnu' or the POSIX-compliant 'malloc-posix'.  On the
other hand, 'malloc-gnu' sort of implies the errno-setting behavior, since
glibc obeys POSIX in this regard, in which case I don't see a need to
distinguish, and we might as well go with the simpler module 'malloc' that
does it all for everyone.  For fnmatch-gnu, I can see where there are
extensions beyond POSIX, but not in your proposed malloc-gnu.  At any
rate, I don't see a patch for calloc-gnu in your proposed patch.

> 
> 2007-09-02  Bruno Haible  <address@hidden>
> 
>       * modules/calloc-posix: New file.
>       * lib/calloc.c: Include errno.h.
>       (rpl_calloc): Merge the requirements of a glibc-compatible calloc
>       and a POSIX-compatible calloc into a single function. Set ENOMEM
>       when returning NULL.
>       * m4/calloc.m4 (gl_FUNC_CALLOC_POSIX): New macro.
>       * doc/functions/calloc.texi: Mention the calloc-posix module.
>       * lib/stdlib_.h (calloc): New declaration.
>       * m4/stdlib_h.m4 (gl_STDLIB_H_DEFAULTS): Initialize
>       GNULIB_CALLOC_POSIX and HAVE_CALLOC_POSIX.
>       * modules/stdlib (stdlib.h): Substitute also GNULIB_CALLOC_POSIX
>       and HAVE_CALLOC_POSIX.
> 
...
> --- m4/calloc.m4      2 Sep 2007 23:16:14 -0000
...
> +   AC_CACHE_CHECK([whether calloc is POSIX compliant],
> +     [gl_cv_func_calloc_posix],
> +     [
> +       dnl It is too dangerous to try to allocate a large amount of memory:
> +       dnl some systems go to their knees when you do that. So assume that
> +       dnl all Unix implementations of the function are POSIX compliant.
> +       AC_TRY_COMPILE([],

It may be worth considering using AC_COMPILE_IFELSE rather than the
obsolete AC_TRY_COMPILE, now that gnulib requires autoconf 2.59 or better.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG3APx84KuGfSFAYARAvIiAJwMXRgJHh8z/tmJ5B83SrAFmKxdoACdERzE
IiLUpZ/PHWARkv0WnnH+jKY=
=qgwA
-----END PGP SIGNATURE-----