Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!hellgate.utah.edu!cs.utexas.edu!longway!std-unix From: std-unix@longway.TIC.COM (Moderator, John S. Quarterman) Newsgroups: comp.std.unix Subject: Re: ANSI C symbols supported by POSIX Message-ID: <566@longway.TIC.COM> Date: 16 Mar 90 23:28:42 GMT References: <563@longway.TIC.COM> Reply-To: Doug Gwyn Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 46 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: Doug Gwyn In article <563@longway.TIC.COM> std-unix@uunet.uu.net writes: > Which symbols from the ANSI C header namespace are guaranteed to > be available to a Strictly Conforming POSIX Application? There are two 1003.1 conforming C environments, C standard and common-usage C. In the C standard environment, those portions of the C standard referenced by 1003.1-1988 Chapter 8 are required for implementation conformance. While section 8.1 lists only the specific standard C functions that 1003.1 requires to be supported, it also stipulates that the requirements in the indiciated sections of the C standard be obeyed. Those do include macro definitions and external object declarations, as well as function declarations. In fact 1003.1-1988 section 8.2.1.2 refers to the C language stdin, etc. so clearly 1003.1 intends that these have meaning. 1003.1 cleverly side-stepped the issue of defining what the cited functions should do for the "common-usage C" binding to 1003.1, which makes that pretty much a nonstandard flavor of the standard that you should avoid specifying in procurement contracts etc.. 1003.1, even in the C standard binding variant, does not mandate full ANSI/ISO C standard conformance; however, it does require that the implementor announce clearly that he does not conform to the C standard if in fact that is the case. >Specific question: > Can a Strictly Conforming POSIX Application use "stdin", for > example by calling "getc(stdin)"? Yes. >Arguments about the specific question: >No, because... > ...The POSIX Standard specifically names the symbols and terms > adopted from the C Standard, in section 2.8.1, and stdin is > not among them. Section 2.8.1 is not an exclusive list; other symbols (e.g. those in section 8.1) are also required, and by the argument I gave above so are stdin, etc. What I recommend is that when specifying acquisition of a system you always specify ANSI C conformance in addition to IEEE 1003.1 conformance. 1003.1 was never intended to stand independently of the standard C library. Volume-Number: Volume 18, Number 78