Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Header problems Message-ID: <7412@brl-smoke.ARPA> Date: 3 Mar 88 22:30:55 GMT References: <2550049@hpisod2.HP.COM> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 40 In article <2550049@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >While trying to avoid "name space pollution" is admirable, >these requirements require implementations to break thousands of existing >applications, or to define all constants in all headers. I don't understand your argument. It is true that the incredibly sloppy UNIX headers need to be cleaned up for ANSI C conformance. Based on the amount of trouble I've had porting applications due to name space pollution, I think this is a Good Thing. Unlike IEEE 1003.1, X3J11 is not nearly so concerned about allowing vendors to rubber-stamp "standard conforming" on whatever crufty implementations they may have already produced. A conforming ANSI C implementation will be considerably "cleaner" than is usually the case in existing practice. This was specified deliberately in order to actually promote application program portability among future standard-conforming implementations, rather than pay this all-important goal lip service while not resolving the most important portability issues. The current draft specifies the headers in which standard library functions are declared and those in which standard "manifest constant" macros are defined. With two exceptions (NULL and size_t), each such symbol is found in precisely one header. (Earlier drafts had this messed up.) size_t is defined in each header for which there is a reference to it in the corresponding section of the standard. >I don't know in which header to define "NULL", since it is >required by facilities that also require other constants, >and I am not allowed to add these other constants to . NULL is defined in (for historical compatibility) and in (where it really belongs). If you need to use the symbol, you should include one or both of these two headers. Of course NULL is only a "convenience" macro, because it is clear how to write any type of null pointer constant in the language proper. It was included in the propsoed standard because so much code uses it, not because it is technically necessary for portability. The implementor should put something like the following in each header: #define NULL 0 P.S. These are my view, not necessarily X3J11's.