problem with cc compiler

[Doug Gwyn]

In article <712 at unsvax.NEVADA.EDU> willey at arrakis.uucp (James P. Willey) writes:
>... I finally realized that the function name "read" was the culprit.
>Are there other function names to avoid with the cc compiler, or any
>others for that matter?

I assume that your problem was that getchar() eventually called read(),
expecting the version in the system's C library, but instead found one
you had written as part of your program.

Standard-conforming C implementations are quite constrained in this
regard, and would not have invoked your read() function by mistake.
Unfortunately, you have a C implementation that evolved in the "bad
old days" before the name-space pollution problem drew the attention
that it deserved.  Assuming you have a UNIX system, you can obtain a
complete list of external symbols referred to by routines in the C
library, which is therefore a list of external symbols you need to
avoid defining in your programs, by something like the following:
	nm /lib/libc.a | grep 'U _' | sed 's/.* //'
(Details depend on your particular system.)  There are also macros
in the standard headers that you need to watch out for:
	cat /usr/include/*.h | grep '^[	 ]*#[	 ]*define' |
	sed 's/^[ 	]*#[ 	]*define[ 	]*\([^(]*\).*/\1/'
You can also get burned by a few other symbols in system headers,
notably typedefs such as "ushort" or "ushort_t", occasionally
structure tags and other names.  Also avoid using names that start
with an underscore; for example the following will break in almost
any UNIX C implementation (due to its use of _iob in the definition
of getchar):
	#include <stdio.h>
	func() {
		int _iob[10];
		_iob[0] = getchar();
	}

Generally, if you can manage to avoid a name collision using a pre-
Standard C implementation, you're entitled to consider it a minor
miracle.