Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!labrea!rutgers!cmcl2!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.std.c Subject: Re: __STDC__ and POSIX Message-ID: <9436@smoke.BRL.MIL> Date: 19 Jan 89 14:13:13 GMT References: <9391@smoke.BRL.MIL> <8731@megaron.arizona.edu> <9405@smoke.BRL.MIL> <860@auspex.UUCP> <866@auspex.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 79 In article <866@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >when he meant >>mean anything from "they define 'fileno' as a macro in " to Ok, I used fdopen() as my example of a POSIX name in instead of fileno() but the principle is the same. These are simply prohibited from being visible there in an ANSI C Standard conforming implementation. When the POSIX conflict with this (extremely important, I think) general anti-pollution principle was discovered, there was much frantic activity (since both groups were meeting at the same time in different locations) to try to work out a resolution. These issues were not getting resolved satisfactorily, and X3J11 sent a letter to P1003 with X3J11's recommendation for how to best provide extensions like this while remaining ANSI C Standard conformant. (Basically the idea was to require some symbol be defined before inclusion of a standard header to enable the extensions; this symbol could have been predefined in POSIX environments, to make it convenient.) The actual scheme adopted in the final IEEE Std 1003.1 wasn't quite what X3J11 had suggested; in fact it's sort of the converse. They permit an application (NOT the implementation) to define the macro _POSIX_SOURCE, which (a) makes available POSIX extensions and (b) removes unconstrained extensions that Std 1003.1 would otherwise have permitted in headers. However, the intent appears to be that POSIX-mandated extensions be available in the headers even when _POSIX_SOURCE is NOT defined by the application, and that contradicts ANSI C. I think the logical consequence of all this is that in a simultaneously ANSI C and IEEE 1003.1 conforming implementation, applications would have to be sure to defined _POSIX_SOURCE if they want to get at the POSIX-specific symbols in those headers specified by the C Standard. This is obviously a nuisance, and consequently it is probable that there will be few attempts to provide simultaneously-conforming implementations and fewer attempts on the part of applications to use them. This is a real lossage. My hope is that in the UNIX world the following slightly cheating position will become widely adopted as a compromise solution of most benefit to the programmer who is also concerned with portability issues: The new default compilation environment predefines _POSIX_SOURCE "on behalf of the application", i.e. it is NOT considered as being provided by the official "implementation" but by the "program" being compiled. The shared standard headers key on _POSIX_SOURCE to enable the POSIX extensions beyond the ANSI C specification. Except for the header extensions enabled by _POSIX_SOURCE, the ANSI C Standard is obeyed. __STDC__ is defined as 1. As an acceptable but slightly less convenient alternative that can be coped with easily by POSIX applications adding -D_POSIX_SOURCE to CFLAGS in Makefiles: The new default compilation environment does NOT predefine _POSIX_SOURCE. The shared standard headers key on _POSIX_SOURCE to enable the POSIX extensions beyond the ANSI C specification. The ANSI C Standard is obeyed. __STDC__ is defined as 1. The key to this is that, because the "program" is defining the identifier _POSIX_SOURCE, which is in the name space reserved for implementations, technically by the ANSI C Standard the realm of "undefined behavior" has been entered. Basically, POSIX implementations would define the behavior in this case to be that outlined above. This solution does NOT work if it is the "implementation" that is considered to be defining _POSIX_SOURCE.