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.
