From owner-cvs-lib  Tue Mar 28 02:09:09 1995
Return-Path: cvs-lib-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA05681 for cvs-lib-outgoing; Tue, 28 Mar 1995 02:09:09 -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 CAA05664; Tue, 28 Mar 1995 02:09:01 -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 CAA18347; Tue, 28 Mar 1995 02:08:33 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA18620; Tue, 28 Mar 1995 20:05:49 +1000
Date: Tue, 28 Mar 1995 20:05:49 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199503281005.UAA18620@godzilla.zeta.org.au>
To: CVS-commiters@time.cdrom.com, cvs-lib@time.cdrom.com, jkh@freebsd.org
Subject: Re: cvs commit: src/lib/libc/stdlib strhash.c
Sender: cvs-lib-owner@freebsd.org
Precedence: bulk

>  Modified:    lib/libc/stdlib strhash.c
>  Log:
>  Fix a missing _hash() to prevent namespace pollution with the db/hash routines.
>  Grrr.  If the dbhash routines weren't grossly overengineered I wouldn't
>  even need to do this! :-(

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
implementation uses it for some other purpose.  Since you control the
implementation, this is not much of a problem in practice.  In the current
implementation, you just have to check that there are no declarations for
globals named `_hash' in scope.

However, for debugging it is convenient to make even the names of internal
static objects and functions unique.  Names in the `foohash' module could
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.

Bruce