Re: Why not auto?

Ben Pfaff <blp@xxxxxxxxxxxxxxx> writes:
> Keith Thompson <kst-u@xxxxxxx> writes:
>
>> Apart from EXIT_SUCCESS being undeclared (it's in <stdlib.h>, not
>> <stdio.h>), I'm not sure. I had thought that C89/C90 allows implicit
>> int only for functions, not for objects, but I might be mistaken. (I
>> just took a quick look through the C90 standard and didn't find
>> anything definitive.)
>>
>> I'm sure someone here can provide the appropriate chapter and verse.
>
> It's hard to provide exact C&V that prohibits something that's
> not prohibited. My C standard notes say the following:
>
> In C90, a declaration without a type specifier had `int'
> supplied by default, called "implicit `int'" (C89 6.5.2#3).
> C99 disallows this practice, requiring that a type specifier
> be explicitly supplied (C99 6.7.2#2).

It's not just not prohibited; there's an explicit rule that says that
a declaration with no type specifier is implicitly of type int. I
missed it because it's fairly well hidden in C90 6.5.2:

Constraints

Each list of type specifiers shall be one of the following sets
(delimited by commas, when there is more than one set on a line);
the type specifiers may occur in any order, possibly intermixed
with the other declaration specifiers.

-- void
-- char
[snip]
-- int, signed, signed int, or no type specifiers
[snip]

Semantics

[snip]

Each of the above comma-separated sets designates the same type,
except that for bit-fields, the type signed int (or signed) may
differ from int (or no type specifiers).

So it looks like I was correct to think that I might be mistaken.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.

Relevant Pages

  • Re: These are identical, right? char const* and const char*
    ... There are a slew of type specifiers that can appear adjacently in ... Some orderings tend to be used ... One thing I actually like about teaching Java is that when anyone asks why ... unsigned int, ...
    (comp.lang.cpp)
  • Re: Serious conformance bug in
    ... Each list of type specifiers shall be one of the following sets ... (delimited by commas, when there is more than one set on a line); ... synonyms for "unsigned long long int". ... It means that when you see "int, signed, or signed int" in the list, it ...
    (comp.lang.c)
  • Re: These are identical, right? char const* and const char*
    ... There are a slew of type specifiers that can appear adjacently in ... thought that was an interesting proposition, do I established the habit of ... right if precedence didn't override the rule. ... unsigned int, ...
    (comp.lang.cpp)
  • Re: INT_MIN as decimal
    ... Yes, but the expression has type long, not int. ... Since -32768L _is_ within the range of your signed int, ... Note that only C99 has the potential for implementation defined signals ... C90 the conversion is always implementation defined (i.e. unspecified ...
    (comp.lang.c)
  • Re: What is the right interpretation?
    ... The type "long int" followed by the type long ... I want to be clear that I'm not claiming that this is the only possible algorithm, or even the best algorithm, merely that any conforming implementation of C must interpret type specifiers in the same way that this algorithm does. ...
    (comp.std.c)