JTC1/SC22/WG14 N612

                     Document Number:  WG14 N612/X3J11 96-076


                        C9X Revision Proposal
                        =====================

Title: Deprecate 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: [email protected]
Telephone Number: +1-410-278-8945
Fax Number: +1-410-278-2934
Sponsor: X3J11
Date: 1996-09-13
Document History:  proposal, based on previous discussions
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(/*int*/ r);
		/*int*/ pass_thru(r)
		/*int r;*/	// NOT ADDRESSED IN THIS
				//  PROPOSAL
		{ /*int*/ s = r;
		  /*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
	deprecation of this feature of "int" being
	implicitly assumed for declarations with no type
	specifiers.

Proposal: The intent is to deprecate use of implicit "int"
	as illustrated above, except for undeclared
	parameters for function definitions using identifier
	lists.  (That might be worth deprecating, 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

	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.