Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #66984 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2015-08-07 18:19 -0700 |
| Last post | 2015-08-11 16:37 -0700 |
| Articles | 8 on this page of 48 — 13 participants |
Back to article view | Back to comp.lang.c
Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-07 18:19 -0700
Re: Untyped Variables Lőrinczy Zsigmond <nospam@for.me> - 2015-08-08 06:53 +0200
Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 11:09 -0400
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 12:09 -0700
Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 14:24 -0400
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 12:54 -0700
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-08 16:06 -0700
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 17:29 -0700
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-09 17:52 -0700
Re: Untyped Variables Ian Collins <ian-news@hotmail.com> - 2015-08-10 12:57 +1200
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:41 -0700
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:06 -0700
Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-08 19:44 -0400
Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 20:34 -0400
Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-09 02:03 +0000
Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-08 22:52 -0400
Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-09 04:57 +0000
Re: Untyped Variables Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-09 09:58 -0600
Re: Untyped Variables Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:54 -0700
Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-09 16:59 -0400
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-09 18:02 -0700
Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-10 11:01 -0400
Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-10 13:20 -0400
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 16:54 -0700
Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-11 00:20 -0400
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:11 -0700
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:15 -0700
Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-11 00:30 -0400
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-11 16:50 -0700
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-11 17:24 -0700
Re: Untyped Variables Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 01:37 +0100
Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-12 04:46 +0000
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-12 18:12 -0700
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-13 12:08 -0700
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-13 16:25 -0700
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-14 10:36 -0700
Re: Untyped Variables Bartc <bc@freeuk.com> - 2015-08-14 19:13 +0100
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-11 07:58 -0700
Re: Untyped Variables richard@cogsci.ed.ac.uk (Richard Tobin) - 2015-08-10 13:53 +0000
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:29 -0700
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:01 -0700
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 17:42 -0700
Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-11 02:56 +0000
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 16:50 -0700
Re: Untyped Variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 01:39 +0100
Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 19:03 -0700
Re: Untyped Variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 11:21 +0100
Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-11 16:37 -0700
Page 3 of 3 — ← Prev page 1 2 [3]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-10 17:01 -0700 |
| Message-ID | <c2766b55-62de-458d-9a34-7114067bbc11@googlegroups.com> |
| In reply to | #67071 |
On Monday, August 10, 2015 at 8:23:37 AM UTC-7, Keith Thompson wrote:
> richard@cogsci.ed.ac.uk (Richard Tobin) writes:
> > In article <55C69FFA.7050309@verizon.net>,
> > James Kuyper <jameskuyper@verizon.net> wrote:
> >
> >>On 08/08/2015 07:06 PM, David Kleinecke wrote:
> >>...
> >>> I haven't been thinking of constraints as part of syntax. ...
> >
> >>It would be more accurate to say that some constraints constrain the
> >>syntax.
> >
> > It would make sense that a program must conform to both the grammar
> > and the constraints.
> >
> > But in the case of implicit int in C90, the "constraint" in 6.5.2
> > explicitly allows something that is not allowed by the grammar.
>
> Interesting, so it does.
>
> For those who don't have a copy of C90, 6.5.2 covers type
> specifiers. A type specifier is one of void, char, short,
> int, etc. A declaration starts with a sequence of one or more
> declaration specifiers, each of which is a storage-class specifier,
> a type-specifier, or a type-qualifier. The constraint in 6.5.2
> restricts the list of type specifiers to one of a list of sets
> (changed to "multisets" in C99 with the addition of long long,
> though the wording wasn't updated until C11); for example, you
> can't have "int int" or "short long" in a declaration.
>
> One of the permitted sets of type specifiers is:
>
> -- int, signed, signed int, or no type specifiers
>
> So this:
>
> x;
>
> does not satisfy the grammar, but it is permitted by the constraint.
> ("auto x;" or "static x;" is permitted by the grammar.)
>
> (Note that "x;" is ambiguous at block scope, where it could be an
> expression statement; it's unambiguous at file scope where statements
> are not permitted. I think C90 has wording to resolve the ambiguity,
> but I don't know exactly where it does so.)
>
> This is yet another reason to be glad that the implicit int rule
> is no longer with us.
I disagree with that reading of the constraint but lets all just ignore
the problem and never omit a type-specifier.
If C were perfect (IMO) "double" would be "float" and "float" would be
"short float" and "double" would not be a keyword.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-10 17:42 -0700 |
| Message-ID | <ln1tfaejur.fsf@kst-u.example.com> |
| In reply to | #67095 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, August 10, 2015 at 8:23:37 AM UTC-7, Keith Thompson wrote:
>> richard@cogsci.ed.ac.uk (Richard Tobin) writes:
>> > In article <55C69FFA.7050309@verizon.net>,
>> > James Kuyper <jameskuyper@verizon.net> wrote:
>> >
>> >>On 08/08/2015 07:06 PM, David Kleinecke wrote:
>> >>...
>> >>> I haven't been thinking of constraints as part of syntax. ...
>> >
>> >>It would be more accurate to say that some constraints constrain the
>> >>syntax.
>> >
>> > It would make sense that a program must conform to both the grammar
>> > and the constraints.
>> >
>> > But in the case of implicit int in C90, the "constraint" in 6.5.2
>> > explicitly allows something that is not allowed by the grammar.
>>
>> Interesting, so it does.
>>
>> For those who don't have a copy of C90, 6.5.2 covers type
>> specifiers. A type specifier is one of void, char, short,
>> int, etc. A declaration starts with a sequence of one or more
>> declaration specifiers, each of which is a storage-class specifier,
>> a type-specifier, or a type-qualifier. The constraint in 6.5.2
>> restricts the list of type specifiers to one of a list of sets
>> (changed to "multisets" in C99 with the addition of long long,
>> though the wording wasn't updated until C11); for example, you
>> can't have "int int" or "short long" in a declaration.
>>
>> One of the permitted sets of type specifiers is:
>>
>> -- int, signed, signed int, or no type specifiers
>>
>> So this:
>>
>> x;
>>
>> does not satisfy the grammar, but it is permitted by the constraint.
>> ("auto x;" or "static x;" is permitted by the grammar.)
>>
>> (Note that "x;" is ambiguous at block scope, where it could be an
>> expression statement; it's unambiguous at file scope where statements
>> are not permitted. I think C90 has wording to resolve the ambiguity,
>> but I don't know exactly where it does so.)
>>
>> This is yet another reason to be glad that the implicit int rule
>> is no longer with us.
>
> I disagree with that reading of the constraint
Now that I look at it again, I think you're right, and I was wrong.
C90's grammar permits a declaration with no type specifiers, such as
"auto x;". The constraint in 6.5.2 doesn't permit type specifiers to be
omitted where the grammar requires them. It specifies the *meaning* of
a declaration with no type specifiers (namely that it's equivalent to a
declaration with "int" (or "signed", or "signed int", or "int signed").
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.
...
-- int, signed, signed int, or no type specifiers
...
Semantics:
...
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).
I'm fairly sure that early C compiler did permit
x;
at file scope to mean the same thing as
int x;
gcc treats it that way (with just a warning by default), presumably for
backward compatibility.
> but lets all just ignore
> the problem and never omit a type-specifier.
Indeed.
C99 omits the "or no type specifiers" wording, and adds a constraint:
At least one type specifier shall be given in the declaration
specifiers in each declaration, and in the specifier-qualifier list
in each struct declaration and type name.
> If C were perfect (IMO) "double" would be "float" and "float" would be
> "short float" and "double" would not be a keyword.
And "long double" would be "long float"?
There's a long convention of referring to 32-bit and 64-bit
floating-point as single-precision and double-precision, respectively.
There are a lot of things I'd change if I wanted to make C more nearly
"perfect". The names of the floating-point types aren't very high on
that list. (Don't ask; the "list" is purely hypothetical.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-11 02:56 +0000 |
| Message-ID | <mqbo8p$gvd$1@speranza.aioe.org> |
| In reply to | #67099 |
Keith Thompson <kst-u@mib.org> wrote: > David Kleinecke <dkleinecke@gmail.com> writes: (snip on declarations without a type specifier) >> If C were perfect (IMO) "double" would be "float" and "float" would be >> "short float" and "double" would not be a keyword. To avoid the useful reserved work "double"? > And "long double" would be "long float"? > There's a long convention of referring to 32-bit and 64-bit > floating-point as single-precision and double-precision, > respectively. Fortran, I believe since Fortran II, had "DOUBLE PRECISION". IBM S/360 calls the floating point forms short, long, and extended. The mnemonic letters are E, D, and X, so the register add instructions are AER, ADR, and AXR, for 32 bit, 64 bit, and 128 bit, respectively. > There are a lot of things I'd change if I wanted to make C more nearly > "perfect". The names of the floating-point types aren't very high on > that list. (Don't ask; the "list" is purely hypothetical.) Lately I have been doing more VHDL, and a few times have tried to use a reserved word as a name. But then again, that was from the names on an existing schematic. (But VHDL allows one to get around the restriction by putting backslashed around the name.) It is sometimes nice not to have to worry about reserved words. Fortran and PL/I have no reserved words. COBOL has a long list that, as I understand it (never having tried) COBOL programmers always keep nearby. -- glen
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-10 16:50 -0700 |
| Message-ID | <fa3e2bb7-f1ac-468c-83bb-282deec9b26d@googlegroups.com> |
| In reply to | #67065 |
On Monday, August 10, 2015 at 6:55:11 AM UTC-7, Richard Tobin wrote:
> In article <55C69FFA.7050309@verizon.net>,
> James Kuyper <jameskuyper@verizon.net> wrote:
>
> >On 08/08/2015 07:06 PM, David Kleinecke wrote:
> >...
> >> I haven't been thinking of constraints as part of syntax. ...
>
> >It would be more accurate to say that some constraints constrain the
> >syntax.
>
> It would make sense that a program must conform to both the grammar
> and the constraints.
>
> But in the case of implicit int in C90, the "constraint" in 6.5.2
> explicitly allows something that is not allowed by the grammar.
If you are saying that the constraint explicitly legalizes
a;
you are IMO wrong. It legalizes having no type specifier but the
storage-class-specifiers and type-qualifiers remain to fulfill the
grammar's requirement for a declaration-specifier. I've done this
before:
auto a;
const a;
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-11 01:39 +0100 |
| Message-ID | <87h9o6bquz.fsf@bsb.me.uk> |
| In reply to | #67092 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Monday, August 10, 2015 at 6:55:11 AM UTC-7, Richard Tobin wrote: >> In article <55C69FFA.7050309@verizon.net>, >> James Kuyper <jameskuyper@verizon.net> wrote: >> >> >On 08/08/2015 07:06 PM, David Kleinecke wrote: >> >... >> >> I haven't been thinking of constraints as part of syntax. ... >> >> >It would be more accurate to say that some constraints constrain the >> >syntax. >> >> It would make sense that a program must conform to both the grammar >> and the constraints. >> >> But in the case of implicit int in C90, the "constraint" in 6.5.2 >> explicitly allows something that is not allowed by the grammar. > > If you are saying that the constraint explicitly legalizes > a; > you are IMO wrong. It legalizes having no type specifier but the > storage-class-specifiers and type-qualifiers remain to fulfill the > grammar's requirement for a declaration-specifier. I can't see how you arrive at that conclusion. The grammar permits declarations with nothing but type specifiers, and the constraint (which is really a permission in the this case) permits these to consist of no type specifiers. Where do you find support for your view that there must be a storage class or type qualifier when here is no type specifier? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-10 19:03 -0700 |
| Message-ID | <lnwpx2d1jm.fsf@kst-u.example.com> |
| In reply to | #67098 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Kleinecke <dkleinecke@gmail.com> writes:
>> On Monday, August 10, 2015 at 6:55:11 AM UTC-7, Richard Tobin wrote:
>>> In article <55C69FFA.7050309@verizon.net>,
>>> James Kuyper <jameskuyper@verizon.net> wrote:
>>>
>>> >On 08/08/2015 07:06 PM, David Kleinecke wrote:
>>> >...
>>> >> I haven't been thinking of constraints as part of syntax. ...
>>>
>>> >It would be more accurate to say that some constraints constrain the
>>> >syntax.
>>>
>>> It would make sense that a program must conform to both the grammar
>>> and the constraints.
>>>
>>> But in the case of implicit int in C90, the "constraint" in 6.5.2
>>> explicitly allows something that is not allowed by the grammar.
>>
>> If you are saying that the constraint explicitly legalizes
>> a;
>> you are IMO wrong. It legalizes having no type specifier but the
>> storage-class-specifiers and type-qualifiers remain to fulfill the
>> grammar's requirement for a declaration-specifier.
>
> I can't see how you arrive at that conclusion. The grammar permits
> declarations with nothing but type specifiers, and the constraint (which
> is really a permission in the this case) permits these to consist of no
> type specifiers. Where do you find support for your view that there
> must be a storage class or type qualifier when here is no type
> specifier?
The syntax for a declaration, in C90 6.5, indicates that a declaration
must begin with a storage-class-specifier, a type-specifier, or a
type-qualifier. This makes
a;
a syntax error (at file scope, where statements are not permitted).
The constraint in C90 6.5.2 says that "Each list of type specifiers
shall be one of the following sets ...", where "no type specifiers" is
one possibility, grouped with int, signed, and signed int.
The constraint forbids things like "void float" (or "long long", which
was not permitted prior to C99).
6.5.2 specifies the *meaning* of a declaration with no type specifiers,
such as
auto x;
volatile y;
z();
It does not change the context in which such a declaration is
permitted. In particular, it does not override the grammar to
permit a declaration that doesn't have a storage class specifier,
a type specifier, *or* a type qualifier. An empty sequence of type
specifiers is permitted only in a declaration that has a storage
class specifier and/or a type qualifier.
(This differs from what I wrote earlier; I changed my mind.)
I previously said that I thought earlier versions of C permitted a
declaration like x; at file scope. In a 1975 C reference manual
(3 years before K&R1), the syntax of a declaration requires it
to start with a type specifier, or a storage class specifier, or
both, in either order, so apparently I was mistaken on that point.
Some compilers might have permitted such declarations anyway.
(B did permit such declarations at file scope.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-11 11:21 +0100 |
| Message-ID | <87bneeazx3.fsf@bsb.me.uk> |
| In reply to | #67100 |
Keith Thompson <kst-u@mib.org> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>> On Monday, August 10, 2015 at 6:55:11 AM UTC-7, Richard Tobin wrote:
>>>> In article <55C69FFA.7050309@verizon.net>,
>>>> James Kuyper <jameskuyper@verizon.net> wrote:
>>>>
>>>> >On 08/08/2015 07:06 PM, David Kleinecke wrote:
>>>> >...
>>>> >> I haven't been thinking of constraints as part of syntax. ...
>>>>
>>>> >It would be more accurate to say that some constraints constrain the
>>>> >syntax.
>>>>
>>>> It would make sense that a program must conform to both the grammar
>>>> and the constraints.
>>>>
>>>> But in the case of implicit int in C90, the "constraint" in 6.5.2
>>>> explicitly allows something that is not allowed by the grammar.
>>>
>>> If you are saying that the constraint explicitly legalizes
>>> a;
>>> you are IMO wrong. It legalizes having no type specifier but the
>>> storage-class-specifiers and type-qualifiers remain to fulfill the
>>> grammar's requirement for a declaration-specifier.
>>
>> I can't see how you arrive at that conclusion. The grammar permits
>> declarations with nothing but type specifiers, and the constraint (which
>> is really a permission in the this case) permits these to consist of no
>> type specifiers. Where do you find support for your view that there
>> must be a storage class or type qualifier when here is no type
>> specifier?
>
> The syntax for a declaration, in C90 6.5, indicates that a declaration
> must begin with a storage-class-specifier, a type-specifier, or a
> type-qualifier. This makes
> a;
> a syntax error (at file scope, where statements are not permitted).
>
> The constraint in C90 6.5.2 says that "Each list of type specifiers
> shall be one of the following sets ...", where "no type specifiers" is
> one possibility, grouped with int, signed, and signed int.
>
> The constraint forbids things like "void float" (or "long long", which
> was not permitted prior to C99).
>
> 6.5.2 specifies the *meaning* of a declaration with no type specifiers,
> such as
> auto x;
> volatile y;
> z();
>
> It does not change the context in which such a declaration is
> permitted. In particular, it does not override the grammar to
> permit a declaration that doesn't have a storage class specifier,
> a type specifier, *or* a type qualifier. An empty sequence of type
> specifiers is permitted only in a declaration that has a storage
> class specifier and/or a type qualifier.
Yes, I'm sure (now!) that this is the right interpretation. Oddly it
was clarified for me by reading K&R1 when I went to check what used to
be the case. The wording there is much simpler; after giving the syntax
they say "if the type-specifier is missing from a declaration it is
taken to be int". This seems less ambiguous than wording that could be
taken to imply that an empty list is a valid set of type specifiers.
<snip>
> (B did permit such declarations at file scope.)
Right, and, coming from B to old C as I did, that is no doubt part of
the reason why I used to think that "implicit int" was more general than
it ever actually was. But there's another reason. Much more common was
this old syntax (still permitted in C90):
f()
{
...
}
It's possible to assume (and I certainly did) that this syntax is valid
because the type-specifiers can be empty. In fact, its valid because
the declaration-specifiers are specifically optional in a function
declaration. It means you can't (as I unthinkingly thought you could in
the old days) simply remove the function body and append a semi-colon to
turn a function definition into a declaration. In this case you need to
add extern or int or whatever.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-11 16:37 -0700 |
| Message-ID | <25bc2428-e13c-4832-8ecc-3ed5cff15695@googlegroups.com> |
| In reply to | #67098 |
On Monday, August 10, 2015 at 5:39:45 PM UTC-7, Ben Bacarisse wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > On Monday, August 10, 2015 at 6:55:11 AM UTC-7, Richard Tobin wrote: > >> In article <55C69FFA.7050309@verizon.net>, > >> James Kuyper <jameskuyper@verizon.net> wrote: > >> > >> >On 08/08/2015 07:06 PM, David Kleinecke wrote: > >> >... > >> >> I haven't been thinking of constraints as part of syntax. ... > >> > >> >It would be more accurate to say that some constraints constrain the > >> >syntax. > >> > >> It would make sense that a program must conform to both the grammar > >> and the constraints. > >> > >> But in the case of implicit int in C90, the "constraint" in 6.5.2 > >> explicitly allows something that is not allowed by the grammar. > > > > If you are saying that the constraint explicitly legalizes > > a; > > you are IMO wrong. It legalizes having no type specifier but the > > storage-class-specifiers and type-qualifiers remain to fulfill the > > grammar's requirement for a declaration-specifier. > > I can't see how you arrive at that conclusion. The grammar permits > declarations with nothing but type specifiers, and the constraint (which > is really a permission in the this case) permits these to consist of no > type specifiers. Where do you find support for your view that there > must be a storage class or type qualifier when here is no type > specifier? If the committee that wrote the Standard wanted to allow a declaration without specifiers, they knew how to say - mark the the specifiers as optional - as they did with function definition.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.lang.c
csiph-web