fred@mindcraft.com (Fred Zlotnick) (03/16/90)
From: fred@mindcraft.com (Fred Zlotnick)
In Mark Horton's new book, Portable C Software (Prentice-Hall), there are
tables describing which symbols are supported from which headers in each
of various systems and standards. Looking at the table for <stdio.h>, I
noticed that the symbols stdin, stdout and stderr are marked as not
supported in POSIX. At first I thought that this was an error, but now
I'm not so sure.
General question:
Which symbols from the ANSI C header namespace are guaranteed to
be available to a Strictly Conforming POSIX Application?
Specific question:
Can a Strictly Conforming POSIX Application use "stdin", for
example by calling "getc(stdin)"?
Arguments about the specific question:
Yes, because...
...the POSIX standard supports getchar(), whose semantics are
adopted from the C Standard where they are defined to be
getc(stdin).
...the POSIX standard defines the symbol STDIN_FILENO as the
file descriptor associated with stdin (8.2.1.2), so by
implication stdin is supported.
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.
Obviously similar arguments exist about stdout/stderr. Note that the
symbols stdin, stdout and stderr are unambiguously part of the reserved
name space (at least, if _POSIX_SOURCE is defined in the right place.)
That's not the issue, though, as the names "signal" and "mbtowc" are also
part of the reserved name space but those functions are not supported.
Fred Zlotnick
--
-------------------------------------------------------------------------------
Fred Zlotnick | "You can't overlook, the lack, Jack,
fred@mindcraft.com | of any other highway to ride."
...!{decwrl,ames,hpda}!mindcrf!fred |
Volume-Number: Volume 18, Number 75std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/17/90)
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