JTC1/SC22/WG14
N661
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: [email protected]
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.