Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!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: <9456@smoke.BRL.MIL> Date: 20 Jan 89 16:52:13 GMT References: <9391@smoke.BRL.MIL> <8731@megaron.arizona.edu> <9405@smoke.BRL.MIL> <860@auspex.UUCP> <866@auspex.UUCP> <9436@smoke.BRL.MIL> <399@jhereg.Jhereg.MN.ORG> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 83 In article <399@jhereg.Jhereg.MN.ORG> mark@jhereg.MN.ORG (Mark H. Colburn) writes: >It is possible, I think, to put together a header which conforms to >both standards. For example: [universal defines] >#ifdef _POSIX_SOURCE [POSIX-specific defines] >#endif /* _POSIX_SOURCE */ >In the example above, the POSIX related defines will only be used if >_POSIX_SOURCE is defined. Therefore, if it is not defined, there should be >no namespace pollution. Fine, and an implementation that simultaneously conforms to both standards has to use a technique like that. The practical problem is that many POSIX vendors do not want to force their customers to #define _POSIX_SOURCE in their source code in order for the POSIX definitions to become visible. They rather prefer that these definitions be visible without the extra work on the part of the application. Mostly this is because they would like to be able to use their new POSIX environment to compile existing UNIX applications without having to change said applications. is not the best example of the problem; is a better one. >I would hope that ANSI is not attempting to say that the only materail that >is allowed in an ANSI C conforming header is that material which is in the >ANSI C standard. No, but any extra stuff in the standard headers must either use only those identifiers reserved for implementations (i.e. underscore-names), or else the extra stuff must be protected by a conditional using a name in the implementation's reserved name space (as in your example). The rationale for the latter usage is that an application, by defining a symbol reserved for implementations, has entered the realm of "undefined behavior", which permits an escape from the otherwise stringent ANSI C constraints. >I have always felt that the ANSI C position on namespace pollution was a >little parochial. Obviously, it is causing problems with other ongoing, >and useful, standards such as IEEE 1003 (POSIX). Excuse me, but as acting liaison between the two groups I must say that I don't think 1003.1 ever quite understood this issue as well as X3J11. Certainly the solution adopted by 1003.1 (_POSIX_SOURCE) doesn't properly address the issue. It is THAT, combined with the mess that constitutes existing practice in this area, that is causing problems. The name space anti-pollution guarantee for portable programming is one I find quite valuable. In fact I don't see any viable alternative for specifying a system-independent C standard. I wish 1003.1 had done as well in the specifications for their own headers.. Feel free to blame me for not doing a good enough job as liaison. >I must be confused here, because I do not understand how an application >can be both ANSI C conforming and P1003.1 conforming if it is attempting >to use features which only are available in 1003.1. Please read more carefully. I said "implementation", not "application". >If the application is using only those features available to ANSI C, >then it would be able to #undef _POSIX_SOURCE, or just ignore >_POSIX_SOURCE. A strictly conforming ANSI C application cannot #undef _POSIX_SOURCE, and in any event maximally-portable ANSI C programs are supposed to be writable without reference to the POSIX standard. The joint X3J11/P1003 goal is for such applications to work unchanged in a simultaneously ANSI C and POSIX conforming implementation. >... why should the application have to define it. It should maybe >test for it, if it going to optionally use 1003.1 facilities. Because IEEE Std 1003.1 SAYS the application, not the implementation, optionally defines _POSIX_SOURCE. >I think that an application which is being developed for strict ANSI C >environments on a P1003.1 conforming system should take additional steps, >such as #undef _POSIX_SOURCE, simply to make sure that the available >extensions in 1003.1 are not used. Sorry, that is not proper to require for portable use of a system- independent programming language. How would you feel if the Pascal standard said "Portable programs must XXX in order to be sure that they will work on VMS systems, and YYY to be sure they work on DOS, and ..."?