rk9005@cca.ucsf.edu (Roland McGrath) (02/25/88)
I know about most of ANSI's requirements and limitations on
the name space that can be consumed by an implementation's library.
In the GNU C library, I'm using _open, _read, etc., which will actually
exist in the GNU system to avoid linking in the nonstandard names
that would be called by standard functions (fopen, fread, etc.).
There is, however, one point I am not clear on.
With the following user program
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)
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.
c) What else?
Whatever the answer to this, I think it should be clearly
stated in the standard.
--
Dick Karpinski Manager of Unix Services, UCSF Computer Center
UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (11-7)
BITNET: dick@ucsfcca or dick@ucsfvm Compuserve: 70215,1277
USPS: U-76 UCSF, San Francisco, CA 94143-0704 Telemail: RKarpinski gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/26/88)
In article <1156@ucsfcca.ucsf.edu> roland@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.
rk9005@cca.ucsf.edu (Roland McGrath) (02/28/88)
Thank you, Doug. If you say it's clear, I will gladly accept it. I didn't know the answer to my question because I have not read the entire standard; I have only focused on the portion that defines the library, since that is what I'm writing. -- Dick Karpinski Manager of Unix Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (11-7) BITNET: dick@ucsfcca or dick@ucsfvm Compuserve: 70215,1277 USPS: U-76 UCSF, San Francisco, CA 94143-0704 Telemail: RKarpinski