OpenSolaris

Printable Version Enter a New Search
Bug ID 6369040
Synopsis there should be but one synonyms.h file outside of libc
State 10-Fix Delivered (Fix available in build)
Category:Subcategory library:other
Keywords
Responsible Engineer Roger Faulkner
Reported Against
Duplicate Of
Introduced In
Commit to Fix snv_32
Fixed In snv_32
Release Fixed solaris_nevada(snv_32)
Related Bugs 6362982 , 6370388
Submit Date 5-January-2006
Last Update Date 23-January-2006
Description
To avoid namespace pollution, that is, to allow applications
to have their own definitions of common functions like memcpy()
that are provided by libc and are also called from other parts of
the system (other system-supplied libraries), the common scheme
of providing an alias for such functions is employed, namely to
have two symbols for the same function, one with a leading
underscore to emphasize its system-reserved nature:
	memcpy()
	_memcpy()
This is accomplished via "#pragma weak memcpy _memcpy" in the
libc source code for the function.

The rule is, all calls to memcpy() from within system-supplied libraries
must call the leading underscore version.  The non-leading underscore
version is provided for applications to call (or ignore).  This way, the
system-supplied libraries will not malfunction just because the application
to which they are linked defines its own version of memcpy(), with
different arguments and semantics from libc's version of memcpy().

The rule is implemented, for the most part, by having library source
files include a special header file before all other headers:
	#include "synonyms.h"
which contains #define statements such as:
	#define	memcpy	_memcpy
and etcetera for all such function name pairs.

The source code calls memcpy(), but the generated code calls _memcpy().
This makes the files lintable and straightforwardly readable.

The problem is, there are too many instances of files named "synonyms.h":

usr/src/lib/common/inc/synonyms.h
usr/src/lib/libc/inc/synonyms.h
usr/src/lib/libcrypt/inc/synonyms.h
usr/src/lib/libgen/inc/synonyms.h
usr/src/lib/libcurses/screen/synonyms.h
usr/src/lib/libmail/inc/synonyms.h
usr/src/lib/libresolv/synonyms.h
usr/src/lib/libresolv2/include/synonyms.h
usr/src/lib/librsm/inc/synonyms.h
usr/src/ucblib/libucb/port/gen/synonyms.h

These files are almost all the same, but not quite.
Also, they are not included in all the places that need them.

The first file in the list, in lib/common/inc, was intended to
replace all of the others, but this has not happened yet
(it is happening now, with this bugid).

The libc-specific one must remain libc-specific because libc
both defines and uses its own defined functions.  See bugid:

6362982 namespace pollution/protection in libc

The common one should be renamed:

usr/src/lib/common/inc/c_synonyms.h

to avoid confusion as to which synonyms.h is being included
and to emphasize that it is defining aliases only for functions
implemented in libc.

The remainder of the files should either be deleted or renamed
to some other locally-meaningful name which in turn includes
c_synonyms.h and appends locally-meaningful #defines.

This change requires small modifications to about 250 library source
files.  This will result in about 25 libraries becoming namespace
pollution-free, among them, notably:
        libnsl
        libcrypt
        libresolv
        libresolv2
        libmd5
        librt
        libcmd
        libgen
and provides a simple Makefile-enforced rule, 'fnamecheck',
for requiring that they stay pollution-free:

all : $(LIBS) fnamecheck

The rule can be added to other library Makefiles if/when they
become pollution-free.

See the suggested fix for the details.
Work Around
N/A
Comments
N/A