Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!uflorida!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.std.c Subject: Re: __STDC__ and non-strictly conforming ANSI C compilers Message-ID: <9208@smoke.BRL.MIL> Date: 16 Dec 88 21:28:14 GMT References: <3236@pegasus.ATT.COM> <1988Dec15.183200.2395@utzoo.uucp> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 33 In article <1988Dec15.183200.2395@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >A compiler which will correctly compile any strictly-conforming program, >and will diagnose any violation of the standard, has every right to >define __STDC__ as 1 no matter how many extensions it also accepts. This is correct, and the point should be emphasized that there are standard-conforming ways to add many common extended features; if there is a standard-conforming way to implement them, then that should be used, and __STDC__ continue to be defined (as 1). One really easy way to continue to support such things as "near" in a standard-conforming environment is to require the applications that need these historical but non-standard features to #include a header that the implementation provides to define them, e.g. #include /* gets "near", etc. */ near int array[1000]; Of course what such a header would do is #define near __near /* map to built-in conforming keyword */ As Henry pointed out, functions can be added to the standard C library, so long as the implementation of the standard functions does not use them. I have to disagree that defining __STDC__ as non-1 values, specifically 0, is a good idea. Since there is no standard meaning for that, the only use in portable programming would be #if __STDC__ == 1 which as I pointed out previously is quite undesirable. #ifdef __STDC__ should suffice; however, #if __STDC__ is what I use, just in case some implementation is stupid enough to #define __STDC__ 0 for a non-conforming environment, but I hope that nobody does that.