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: gwyn@arl.mil
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.