GNU bug report logs - #6789
propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jim Meyering <jim <at> meyering.net>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#6789: closed (propose renaming gnulib memxfrm to amemxfrm
 (naming collision with coreutils))
Date: Sun, 07 Aug 2011 15:54:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sun, 07 Aug 2011 17:52:24 +0200
with message-id <87ipq9jk1z.fsf <at> rho.meyering.net>
and subject line Re: bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)
has caused the GNU bug report #6789,
regarding propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
6789: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6789
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> CS.UCLA.EDU>
To: Bug-gnulib <bug-gnulib <at> gnu.org>
Cc: Bruno Haible <bruno <at> clisp.org>, Bug-coreutils <bug-coreutils <at> gnu.org>
Subject: propose renaming gnulib memxfrm to amemxfrm (naming collision with
	coreutils)
Date: Tue, 03 Aug 2010 12:46:21 -0700

On 2009-03-07 Bruno Haible wrote:

> Paul Eggert has written the module 'memcoll', which generalizes the 'strcoll'
> function to work on strings with embedded NULs.

> Here is the generalization of 'strxfrm' to strings with embedded NUL bytes.

Sorry, I didn't really notice this email until just now.  As it happens,
coreutils has had an memxfrm implementation since 2006, which
it never exported to gnulib.  The coreutils memxfrm is closer to how
strxfrm behaves, in that it does not allocate memory: it relies on the
caller to do memory allocation.  The signatures differ as follows:

  // coreutils returns number of bytes that were translated,
  // (or would be translated if there were enough room).
  // It also sets errno on error.
  size_t memxfrm (char *restrict dst, size_t dstsize,
		  char *restrict src, size_t srcsize);

  // gnulib returns pointer to destination, which is possibly-different if
  // the destination wasn't large enough.  It updates *DSTSIZEPTR to
  // the newly allocated size, if it allocated storage.  It returns
  // NULL (setting errno) on error.
  char *memxfrm (char *src, size_t srcsize, char *dst, size_t *dstsizeptr);

For coreutils, the coreutils interface is more memory-efficient,
because malloc is invoked at most once when comparing two lines.  If
the small buffer on the stack isn't large enough to hold the
translated output for both strings, the two calls to memxfrm will tell
sort.c exactly how big the buffer should be, and it can invoke malloc
just once and then invoke memxfrm again (twice) to successfully do the
translation.

The gnulib interface is more convenient for applications that don't
care about this sort of memory optimization, and I expect that for
some (large) cases it is faster because it sometimes avoids translating
the same chunk twice.  So it's useful as well.

However, the name "memxfrm" isn't well-chosen for the gnulib interface.
As a general rule, the mem* functions do not allocate memory, and
it's confusing that memxfrm is an exception.

So I propose that the gnulib memxfrm be renamed to something else, to
reflect the fact that it allocates memory.  I suggest the name
"amemxfrm", as a leading "a" is the usual convention for variants that
allocate memory (e.g., "asprintf").

I guess the coreutils memxfrm could also be migrated into gnulib,
afterwards.

[Message part 3 (message/rfc822, inline)]

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> CS.UCLA.EDU>
Cc: 6789-done <at> debbugs.gnu.org
Subject: Re: bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming
	collision with coreutils)
Date: Sun, 07 Aug 2011 17:52:24 +0200

Paul Eggert wrote:
> On 08/09/10 09:25, Bruno Haible wrote:
>
>> The contents of the 'allocated' buffer is scratch, therefore malloc + free
>> should be faster than realloc...
>>
>> Also, the '3 * (lena + lenb)' guess is pessimistic; it is possible that
>> it may return with ENOMEM when in fact strxfrm's real needs would not
>> lead to ENOMEM.
>
> Thanks again; I installed this:
>
> * src/sort.c (compare_random): Use free/xmalloc rather than
> xrealloc, since the old buffer contents need not be preserved.
> Also, don't fail if the guessed-sized malloc fails.  Suggested by
> Bruno Haible.

This was resolved a year ago.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.