Re: is order urgent doubt

jacob navia wrote:
Walter Roberson wrote:
In article <g248q6$3u7$1@xxxxxxxx>, jacob navia <jacob@xxxxxxxxxx> wrote:

6.7.2 Type specifiers

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.

Notice that bit about "in any order". So long long int is the
same as long int long .

And why is not long int, then long?

... but it is: All of `long', `long int', and `int long'
describe the same type.

What about

int int int m;

Doesn't match any of the combinations listed as legal,
and is thus illegal.

And any kind of nonsense you can think about?

long signed long int,

Legal.

signed long int long,

Legal.

signed long signed long,

Illegal; no listed combination has `signed' twice.

signed int long signed long int

Illegal; no listed combination has `signed' twice or
`int' twice.

long int long int
long int int long

Both illegal; no listed combination has `int' twice.

I just use the last one parsed.

As long as you issue a diagnostic for the unlicensed
combinations, you can do whatever you like with the faulty
source code. (Hmmm: How do you distinguish `long' from
`long long' on a "last one parsed" basis? Maybe that's
the crux of the issue ...)

I'll agree that the Standard's language in this section
is deficient in one respect: It speaks of the combinations
as "sets" when it really ought to say "multisets." In C89
"sets" was fine, but C99's introduction of `long long' brought
in the notion of the number of times an element is present,
and this is foreign to a plain set (it either contains the
element or it does not; there's no "how many" idea). By
concentrating too closely on the "set" notion you may have
been misled into thinking that `double double trouble;' is
a legitimate declaration of what's normally called a `double',
but it's not.

--
Eric.Sosman@xxxxxxx
.

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: 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: Why not auto?
    ... >> int only for functions, not for objects, but I might be mistaken. ... >> just took a quick look through the C90 standard and didn't find ... Each list of type specifiers shall be one of the following sets ... the type signed int may ...
    (comp.lang.c)
  • Re: What is the right interpretation?
    ... At least one type specifier shall be given in the declaration specifiers in each declaration, ... type specifiers shall be one of the following sets (delimited by commas, ... short, signed short, short int, or signed short int ...
    (comp.std.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)