Date: Tue, 28 Mar 1995 21:51:24 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, jkh@freefall.cdrom.com Cc: CVS-commiters@time.cdrom.com, cvs-lib@time.cdrom.com, jkh@freebsd.org Subject: Re: cvs commit: src/lib/libc/stdlib strhash.c Message-ID: <199503281151.VAA21587@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> You never needed to rename hash() to _hash(). It is static so it doesn't >> contribute to namespace pollution. Adding a leading underscore just moves >> it into the implementation's namespace and might cause problems if the >Well, then we have a problem because the friggin' thing DOES clash when >you try to link anything with it otherwise! :-( :-( What was the problem exactly? `nm *.so' in libc/obj shows no definition of `_hash', so I don't see how dmenu could have linked. (I used nm on *.so instead of on *.o because the `ld -r -x' step removes static names so that you can't debug them :-(. We don't do this for shared libraries where the time savings _might_ be much larger. Hmmm, there must be a lot of missed optimizations for static functions. Their caller can be expected to load the GOT pointer...) >Well, again, I was just trying to avoid clashing with the existing >hash stuff. I'd be more than happy to rename it to hash.c, but when I >had it that way originally it clashed with db/hash.c's include of >hash.h and I didn't want to rename the header and not the >implementation file - that would have been even more confusing. I'll You had to rename the implementation file because the hash.o's would have clashed. >Suggestions? YAhash? :-) Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503281151.VAA21587>