bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH] hash: extend module to deal with non-pointer keys


From: Jim Meyering
Subject: Re: [PATCH] hash: extend module to deal with non-pointer keys
Date: Fri, 02 Jul 2010 00:59:09 +0200

Paul Eggert wrote:
> Re the patch you just reported in:
> <http://lists.gnu.org/archive/html/bug-gnulib/2010-07/msg00005.html>
>
> I assume this is to support the du performance improvement that was proposed 
> in
> <http://debbugs.gnu.org/db/65/6524.html>.

Right.  That's the same as this:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/20857

> I see that you incorporated a further
> improvement in the gnulib patch, namely, support for NULL keys.
>
> The gnulib change seems fine, but I noticed some problems with the coreutils
> part of that earlier proposal.  Among other things, it makes du dump core on a
> (large) test case that I have locally.  I don't know why (perhaps there
> were further fixes to the gnulib part that I didn't get right?).  I found

Thanks for testing those.

Can you give me a backtrace?
Even if your patch is clearly better, I'd like to know
how my code is malfunctioning.

> out about the core dump only because I had independently prepared a patch
> that I think is better: it uses a bit less memory and is quite a bit simpler.
> I'll try to merge my patch with your gnulib change and send it off to
> bug-coreutils in the next day or two.
>
> My patch, by the way, doesn't hash pointer keys: it just uses size_t values
> and casts them to void * (which is what the hash package wants).  This trick
> works on all architectures that I know about, but it isn't guaranteed by
> C or POSIX and the casts are a bit offputting,

Using unions is one way to avoid casts (and certain warnings).

> so it'd be nice if the hash
> package supported hashing size_t keys directly.  That's lower priority, 
> though.



reply via email to

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