Document Number: WG14 N661/J11 97-024 C9X Revision Proposal ===================== Title: Disallow implicit "int" in declarations Author: Douglas A. Gwyn Author Affiliation: United States Army Research Laboratory Postal Address: 801-L Cashew Court, Bel Air, MD 21014, USA E-mail Address: gwyn@arl.mil Telephone Number: +1-410-278-8945 Fax Number: +1-410-278-2934 Sponsor: X3J11 Date: 1997-02-10 Document History: 1996-09-13 proposal WG14 N612/X3J11 96-076 was based on previous Committee discussions. Formal vote is held up pending resolution of a question raised in the Toronto meeting concerning a possible requirement to deprecate a feature before removing it. 1997-01-03 proposal WG14 N646/X3J11 97-009 changed "deprecate" (original suggestion) to "disallow". The present document removes another instance of "no type specifiers" that was previously overlooked. Proposal Category: __ Editorial change/non-normative contribution __ Correction __ New feature __ Addition to obsolescent feature list __ Addition to Future Directions x_ Other (please specify) tighten up syntax Area of Standard Affected: __ Environment x_ Language __ Preprocessor __ Library __ Macro/typedef/tag name __ Function __ Header __ Other (please specify) ______________________________ Prior Art: C++, many other languages with strong typing Target Audience: all C programmers Related Documents (if any): Proposal Attached: x_ Yes __ No, but what's your interest? Abstract: Currently, the C standard (C89) permits the list of type specifiers to be omitted in declarations when it would consist of just "int": extern /*int*/ pass_thru(register /*int*/ r); /*int*/ pass_thru(r) /*int r;*/ // NOT ADDRESSED IN THIS // PROPOSAL { register /*int*/ s = r; register /*int*/ *p = &s; register /*int*/ t = *p; return t; } The origin of this practice is probably the typeless language B that was a precursor to C; early C code often dealt with ints or with types assumed to be conformable with ints (e.g. pointers on the PDP-11), so it was convenient for the programmer to not have to declare the type when it was "just a machine word". With the evolution toward strong typing, however, this facility has become an anachronism that (in some cases) delays the detection of some common programming errors. In discussions at previous WG14 meetings, there was considerable support for at least deprecating this feature of "int" being implicitly assumed for declarations with no type specifiers. This proposal goes farther and disallows the feature. Proposal: The intent is to disallow use of implicit "int" as illustrated above, except for undeclared parameters for function definitions using identifier lists. (That might be worth disallowing, too, but I am not proposing to do so here.) Since a conforming implementation is allowed to accept a program that contains a syntax violation, so long as it also produces a diagnostic, I judged that the most forceful way to make this change while permitting implementors to support existing code was not to simply decree this usage to be an "obsolescent feature", but to go ahead and outlaw it now, which will guarantee diagnostics. Change in 6.5.2 Type specifiers; add new sentence at beginning of first paragraph of Constraints: At least one type specifier shall be given in the declaration specifiers in a declaration. Change in 6.5.2 Type specifiers, Constraints, from: -- int, signed, signed int, or no type specifiers to: -- int, signed, or signed int Change in 6.5.2 Type specifiers, Semantics, from: ... for bit-fields, the type signed int (or signed) may differ from int (or no type specifiers). to: ... for bit-fields, the type signed int (or signed) may differ from int. In the Rationale document, add a new paragraph to 6.5.2 Type specifiers: In C89, all type specifiers could be omitted from the declaration specifiers in a declaration; in such a case "int" was implied. The committee decided that the inherent danger of such a feature outweighed its convenience, and thus this feature was removed. The effect is to guarantee that a diagnostic is produced, which will catch an additional category of programming errors. Implementations may also choose to assume an implicit "int" and continue to translate the program, in order to support existing source code that exploited this feature. Also, there should be a generic editing pass over the C9x draft and Rationale to fix any examples using implicit int; I don't recall seeing any such instances, but this should be checked.