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

Hi Paul, I wrote: > If we add such a wrapper to gnulib, it could be called 'astrxfrm' > > extern char * astrxfrm (const char *s, char *resultbuf, size_t *lengthp); > > and then I would agree to renaming memxfrm -> amemxfrm, for consistency. I'm doing the renaming: 2010-08-14 Bruno Haible

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

On 08/11/10 02:38, Bruno Haible wrote: > extern char * astrxfrm (const char *s, char *resultbuf, size_t *lengthp); Yes, that looks like a useful addition. Thanks for the suggestion.

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

Hi Paul, > 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 > contr

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

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,

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

Paul Eggert writes: > On 08/06/10 01:22, Paolo Bonzini wrote: >> ISAAC is a RNG, so wouldn't that have the same problem above? You >> definitely need to use a hash function, it's just that you do not need a >> cryptographic one. > > I had been thinking of using ISAAC by making the key its seed,

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

Hi Paul, > (Ooo! Ooo! Performance measurements! I love this stuff!) Me too :-) > It depends on the data. In the typical case, "sort" is applied to > text data, which does not contain NUL bytes. The data in that > benchmark contained many NUL bytes. If you take the same benchmark > and unif

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

On 08/07/10 04:40, Simon Josefsson wrote: > I suspect FNV or Xorshift would be faster, since they are so simple: Yes, they'd be faster, but there may be some collision problems with those. FNV would seem better suited, since it's a hash function. I did quick scan for relevant articles and found

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

On 08/06/10 01:22, Paolo Bonzini wrote: > ISAAC is a RNG, so wouldn't that have the same problem above? You > definitely need to use a hash function, it's just that you do not need a > cryptographic one. I had been thinking of using ISAAC by making the key its seed, and asking it to generate some

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

On 08/06/2010 01:29 AM, Paul Eggert wrote: 1) why bother with memxfrm as a tie-breaker? isn't memcmp good enough? If two keys K1 and K2 compare equal, their random hashes are supposed to compare equal too. So if memcoll(K1,K2)==0, the random hashes must be the same. Hence we can't just do a

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

On 08/04/10 19:58, Paolo Bonzini wrote: > MD5 is used simply as a kind of "random key generator", so it doesn't > matter. That depends on what one is using "sort -R" for. If one uses it to choose data that are relevant for cryptographic purposes, it might matter. (Admittedly this is unlikely.)

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

On 08/05/2010 01:44 AM, Simon Josefsson wrote: Paul Eggert writes: Come to think of it, looking at gnulib memxfrm gave me an idea to improve the performance of GNU sort by bypassing the need for an memxfrm-like function entirely. I pushed a patch to do that at

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

Paul Eggert writes: > Come to think of it, looking at gnulib memxfrm gave me an idea > to improve the performance of GNU sort by bypassing the need for an > memxfrm-like function entirely. I pushed a patch to do that at >

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

On 08/03/10 16:33, Bruno Haible wrote: > But when the stack buffer is not sufficient, then the use of coreutils memxfrm > is 30% to 70% slower than the use of gnulib memxfrm, with a difference of > 700 μsec at least. (Ooo! Ooo! Performance measurements! I love this stuff!) It depends on the da

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

Hi Paul, > > 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. And I'm sorry that I overlooked you

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

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 no