-----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 <[EMAIL PROTECTED]> > > * 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 [EMAIL PROTECTED] -----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-----
