Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Mar 1995 02:23:10 -0800
From:      "Jordan K. Hubbard" <jkh@freefall.cdrom.com>
To:        Bruce Evans <bde@zeta.org.au>
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:  <6298.796386190@freefall.cdrom.com>
In-Reply-To: Your message of "Tue, 28 Mar 95 20:05:49 %2B1000." <199503281005.UAA18620@godzilla.zeta.org.au> 

next in thread | previous 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! :-( :-(

Give it a try.  Perhaps Nate should look into this too, since it's
possibly something suspicious with the new ld stuff.

> be distinguished from names in the `barhash' module by prefixing them with
> `foo'.  `strhash' is a bad name for a module because names starting with
> `str' are reserved.

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
concur that the name strhash was rather deeply uninspired, but I
didn't expect the clash in the first place and when it happened I was
rather desperate to fix things again quickly.

Suggestions?

					Jordan




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6298.796386190>