[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Perfect hash function generator
> 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.
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>).
I don't see any fix for this for globally-visible names, though using
weak references and private names can help in some cases. But for
functions defined with file scope in the user code (which is most of
the cases I've run into), just putting them in their own include files,
rather than adding them to common include files, is enough.
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 ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |