bug-gnulib
[Top][All Lists]
Advanced

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

Re: new module 'calloc-posix'


From: Jim Meyering
Subject: Re: new module 'calloc-posix'
Date: Tue, 04 Sep 2007 08:09:06 +0200

Bruno Haible <address@hidden> 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.




reply via email to

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