Re: propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)

[Paul Eggert]

On 08/08/10 03:31, Bruno Haible wrote:

>> The point
>> remains, though, that it's confusing that gnulib memxfrm's name begins
>> with "mem", as the mem* functions don't allocate memory.  Would you
>> consider a patch that renames gnulib memxfrm to amemxfrm, or to some
>> other such name?
> 
> No, this is not good. The variant which never allocates memory by itself
> would be more complex to use and slower on average that gnulib's function.

Sorry, but this doesn't seem to address the point.  The name for
gnulib's strxfrm variant should be chosen so that it's not confusing,
regardless of whether some other strxfrm variant exists.  Currently,
no other variant exists in coreutils and I think it unlikely that
coreutils will use any similar variant any time soon, but removing
coreutils memxfrm didn't fix the gnulib confusion.

> Also, functions like 'strdup', 'putenv', 'setenv', 'scandir', 'fts', all
> do dynamic memory allocation without having an 'a' in their name to
> indicate this.

My point was not that the function must start with "a".  After all,
lots of functions allocate memory without having "a" at the front: malloc
is just one example.  All I'm saying is that the gnulib variant shouldn't
use a name starting with "mem", because the mem* names have similar
properties and the gnulib variant departs dramatically from these
properties.

The "strdup"/"strndup" functions are cases in point.  Their names were
controversial, and they had quite some trouble getting into POSIX, precisely
because their names began with "str" but (unlike the other str* functions)
they allocated memory.  It would be better to not go down that same road
again.

Thanks for improving the performance of the gnulib variant, by the way.