To: Deborah Donovan From: David R Tribble on Thu, Feb 5, 1998 11:57 PM Subject: Comments on ISO/IEC CD 9899 (C9X) Message-Id: <2.2.32.19980206023132.008f9d6c@central.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 05 Feb 1998 20:31:32 -0600 To: ddonovan@itic.nw.dc.us From: David R Tribble Subject: Comments on ISO/IEC CD 9899 (C9X) Public Comment Number(s) PC-____ to PC-____ ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-05 Author: David R. Tribble Author Affiliation: Self Postal Address: 6004 Cave River Dr. Plano, TX 75093-6951 USA E-mail Address: dtribble@technologist.com david.tribble@central.beasys.com dtribble@flash.net Telephone Number: +1 972 738 6125, 16:00-00:00 UTC +1 972 964 1729, 01:00-05:00 UTC Fax Number: +1 972 738 6111 Number of individual comments: 1 ------------------------------------------------------------------------ Comment 1. Category: Normative change Committee Draft subsection: 4, 6.8.8, 7.1.3. Title: Useless __STDC__ macro Detailed description: Section 6.8.8 states that the predefined '__STDC__' macro has the value 1, indicating a conforming implementation. Section 4 states fairly clearly just exactly what a "conforming" and a "strictly conforming" implementation are. Section 7.1.3 states exactly what a "reserved" identifier is. While appealing in theory, the '__STDC__' macro is useless in practice. Programmers typically test for '__STDC__' in order to ascertain the answers to the following questions: 1. Does the implementation support the standard keywords and syntax (such as 'const', 'void *', and prototypes)? 2. Does the implementation supply the standard header files (such as and )? 3. Does the implementation supply the standard library functions (such as 'printf' and 'setjmp')? For example, the following fragment is typical for use with compilers that support a "compile in non-ISO K&R mode" switch, in order to allow for correct declarations in both ISO and K&R modes: #ifdef __STDC__ #define P(d) d #else #define P(d) () #endif extern int my_foo P((int arg)); extern void my_bar P((const char *n)); While conforming compilers are allowed to have extensions, some compilers deviate from 7.1.3 by providing keywords that reside in the unreserved namespace. For example, Microsoft Visual C provides the 'near' and 'far' keywords as extensions (for dealing with segmented pointer types on Intel hardware); as such, it is not conforming and so does not define '__STDC__' at all, even though it supports the full ISO C syntax and library. Other vendors, such as Sun, define '__STDC__' but define it to 0, presumably to indicate that they support the syntax and library of ISO C but still have extensions. Some vendors' compilers have a "ANSI/ISO compliance" switch that, when enabled, causes '__STDC__' to be defined as 1, but to cause all nonconforming constructs to be flagged as errors; this is fine in theory, but in practice it cripples a program, usually by disabling the declarations for system functions or by flagging such calls as errors. Unfortunately, 6.8.8 does not define what value '__STDC__' should have in such near-conforming implementations. Theoretically, the '__STDC_VERSION__' macro can be tested to determine what language features are supported. But there is no guarantee that this macro will be defined properly by vendors either. (Indeed, it isn't on many implementations.) Proposal: In order to clarify the issue, in the hopes of providing programmers a more useful macro, I propose that 6.8.8 be changed to the following: __STDC__ The decimal constant 1, indicating a fully conforming implementation, or the decimal constant 0, indicating a conforming implementation with extensions [note]. note: Such extensions would potentially cause some otherwise conforming programs to be nonconforming (such as the addition of keywords that are not reserved in this standard [7.1.3]). Implementations that are not conforming (with or without extensions) or that are incapable of translating strictly conforming programs shall not define this macro. (The very last "shall not" phrase might be considered a bit weak, because it attempts to define what nonconforming compilers cannot do. Such compilers, by their very nature, are not likely to abide by anything a standard has to say.) ------------------------------------------------------------------------