Re: Perfect hash function generator

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Mon, Jul 13, 2009 at 03:35:02PM -0400, der Mouse wrote:
> > First, I'd like the integrate the Jenkins hash function into libc.
> > [...]  As the man page states, the prototype goes into string.h.  The
> > primary reason to make this libc and not e.g. libutil is to allow all
> > parts of the system to use it without pulling in libutil.
> 
> That's a reason to put it in libc, maybe.  It's not a reason to put it
> in string.h, though.

There are already non-standard functions in string.h and I think it
logically fits best. The second alternative would be stdlib.h like e.g.
bsearch.

> As a software author, I find it really _really_ annoying the way each
> new release of NetBSD breaks code that formerly worked by preempting
> new names, formerly in the user's namespace, in common include files
> (such as <string.h>).

Adding new interfaces happens all the time. I consider the collission
chance for this relatively low, see e.g. getline() for much worst
examples.

> I don't see any fix for this for globally-visible names, though using
> weak references and private names can help in some cases.

Weak references don't help if libraries are actually expected to use the
function. The weak reference trick is libc local.

> In this particular case, isn't <string.h>'s contents specified by a
> standard?  Or is that <strings.h>?  Or am I just misremembering?

The content of string.h is part of various standards. If there is sane
behavior for wanting to reuse the name is another question. strings.h is
originally BSD specific.

Joerg