Bruno Haible <[EMAIL PROTECTED]> wrote: > 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. > > 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').
I'm glad you've seen the light! :-) > Since 'calloc' is a little simpler to handle than 'malloc' and 'realloc', > here is first a proposal for 'calloc'. > > 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'm less enthusiastic about this, since it would require nearly every gnulib client to change. How about adding a way to tell gnulib-tool that a module (or just one of its names) is deprecated. Then, assuming both malloc and malloc-gnu module names are accepted and equivalent for several months -- while gnulib-tool emits warnings[*] -- remove the three deprecated aliases. [*] these gnulib-tool warnings would have to be unequivocally clear and _visible_. Currently, gnulib-tool emits so much output that a few new diagnostics may easily go by unnoticed. Thanks for doing this.
