🚀 go-pugleaf

From: Doug Gwyn <uunet!smoke.brl.mil!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