ANSI name space requirements/limitations

[Doug Gwyn]

In article <1156 at ucsfcca.ucsf.edu> roland at rtsg.lbl.gov (Roland McGrath) writes:
>	int main(void) { extern char *open(int); char *s = open(1); }
>where the user never defines the `open' function, what should happen?
>	a) The program uses the system call:
>		int open(const char *name, int flags, int mode)

This doesn't make any sense -- there has been no such declaration.
What there HAS been is a reference to an external function
	char *open(int);

>	b) The linker must generate an "undefined symbol" (or similar)
>	error, i.e., there must be a library containing only standard
>	function and underscore-prefixed ones.

This is not required.  From Section 1.7:
	A conforming implementation may have extensions (including
	additional library functions), provided they do not alter
	the behavior of a strictly conforming program.
Thus, there can be an open() function in the C library.  However,
one consequence of the standard is that it cannot be used in the
implementation of any of the functions specified for ANSI C.  It
can be used by (non-strictly conforming) applications.

Note that this is not a strictly conforming program, because from
Section 3.7:
	If an identifier declared with external linkage is used in
	an expression (other than as part of the operand of a
	sizeof operator), somewhere in the entire program there
	shall be exactly one external definition of the identifier.
The ANSI C implementation is permitted to act as if this injunction
were being obeyed.  Most likely it would generate a reference to an
external function, expecting it to be satisfied during link-editing.
Depending on the sophistication of the linker and on the contents of
the system's C library, any of several things could happen at link
time, including:
	1) There is no "open" extern in the library, so the linker
	reports an "unsatisified external reference".
	2) There is an "open" in the library, but no type information,
	so the linker satisifies the reference by using the "open"
	function found in the library.  This will undoubtedly cause
	the code to malfunction at run time, since the library "open"
	would certainly have a UNIX-compatible interface, unlike what
	the original program specified.
	3) There is an "open" in the library, and linkage type checking
	is supported, so the linker warns of a type mismatch.

>Whatever the answer to this, I think it should be clearly
>stated in the standard.

I think it is.  Obviously it is not withing the scope of the standard
to dictate interpretations for non-conforming programs and/or
implementations.  Such issues have to be resolved in other ways, for
example programmers following specifications for the use of vendor
extensions.

Disclaimer:  This is my own interpretation of the proposed standard,
but I'm pretty sure it's correct.