From owner-freebsd-commit Tue Mar 28 04:02:00 1995 Return-Path: commit-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA10175 for commit-outgoing; Tue, 28 Mar 1995 04:02:00 -0800 Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA10158 for cvs-lib-outgoing; Tue, 28 Mar 1995 04:01:55 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.223.46]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id EAA10142; Tue, 28 Mar 1995 04:01:51 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by time.cdrom.com (8.6.11/8.6.9) with ESMTP id EAA22133; Tue, 28 Mar 1995 04:01:11 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA21587; Tue, 28 Mar 1995 21:51:24 +1000 Date: Tue, 28 Mar 1995 21:51:24 +1000 From: Bruce Evans Message-Id: <199503281151.VAA21587@godzilla.zeta.org.au> To: bde@zeta.org.au, jkh@freefall.cdrom.com Subject: Re: cvs commit: src/lib/libc/stdlib strhash.c Cc: CVS-commiters@time.cdrom.com, cvs-lib@time.cdrom.com, jkh@freebsd.org Sender: commit-owner@freebsd.org Precedence: bulk >> 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