This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Namespace pollution?


On Tue, 2 Nov 1999, Steve Baker wrote:

>   True, but when you include all the usual headers (unistd, stdlib, stdio,
> pwd) and compile against -Wall, --strict-prototypes and get no warnings,
> it's a little frustrating.  The real problem of course are libraries that
> load other libraries, which was what was happening in this case and the
> dynamic linker not flagging the conflict.
> 
>   Perhaps libdl needs improvment?
> 
>   At any rate, it's difficult to know you're not in compliance if you're not
> getting any warnings.  Sue me.

Until the tools improve, one thing you can do is avoid external declarations
that introduce trivial names. If you use trivial names at file-scope, give them
internal linkage:

	static int uname;	/* local uname */
	int foo_uname;		/* global to project or module foo */

Any object or function with external linkage should have some sort of compound
name which, for instance, identifies the module. That minimizes the risk of
clashes.  If you don't adopt such a naming scheme, you will still be
forced to rename your identifier in the event of a clash; in the long run
a preemptive strategy is cheaper. 

One technique I have used in the past is to use a lexically colorizing text
editor, and load it up with clashing keywords. Problem is this becomes large
when you include the latest UNIX standard. I did it for ANSI C only. Then
whenever I typed something that would intrude into a namespace reserved by ANSI
C, it would be instantly colored red. ;)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]