ISO/ IEC JTC1/SC22/WG14 N646

                     Document Number:  WG14 N646/X3J11 97-009

                        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:
Telephone Number: +1-410-278-8945
Fax Number: +1-410-278-2934
Sponsor: X3J11
Date: 1997-01-03
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.
        The present document changes "deprecate" (original
        suggestion) to "disallow" (actually proposed).
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
                -- int, signed, or signed 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.