C declaration grammar

[diamond@tkovoa]

In article <1990Aug7.012657.8398 at NCoast.ORG> ramsey at NCoast.ORG (Cedric Ramsey) writes:

>The grammar for a declaration is as follows (section A8 pg. 210):
>declaration: declaration-specifiers init-declarator-list_opt
>declaration-specifiers: storage-class-specifier declaration-specifers_opt
>	                type-specifier          declaration-specifier_opt
>			type-qualifier          declaration-specifier_opt
>The production doesn't specify any precedence

Precedence is not really a concern, because ALL of the input
storage-class-specifiers, type-specifiers, and type-qualifiers apply to the
same init-declarator-list.  However, if you mean which one is closest to
the init-declarator-list, bound by a node in the syntax tree most closely
located to the leaves, it is the storage-class-specifier, type-specifier,
or type-qualifier which appears closest to the init-declarator-list in the
input, i.e. the rightmost one.

>or order for what should be seen first.

The grammar says that any of them may be seen first.

>For instance, according to this grammar, the following declarations:
>const char static i; or 
>static const char i; or
>static char const i;
>All would be valid.

Yes, they are all valid.

>I don't recall reading anywhere in the manual a mention
>of how the precedence is to be taken. I guess a programmer would have to use
>his or her common sense and write: static const char i = 0xHH;.

const static char i = 0xHH; has exactly the same effect.  Common sense
is needed for another human to read your program, not for a compiler to
process it.

>You guys with ansi compilers can you get away with those ,strang ?, kind of
>declarations.  

Pre-ANSI compilers didn't all have const, but the static and the char
could be in either order.  ANSI suggests that a later ANSI standard
might require the static to go first.

>However, the ansi standard is clear on other precedence rules. Take 
>expressions, for example just by looking at the grammar you can see
>that && has higher precedence than || and * higher than +.

The grammar specifies which operators go closest to the leaves of the
syntax tree.  Some wording in the standard must suggest that the
operations appear to be executed in some precedence that corresponds
to the syntax tree.

>The semantic rules talk about how type specifiers may specified with a
>type qualifier and the semantics for the const/volatile qualifiers but 
>does not say which should come first.

It says that any of them should come first.

It also says that  a = b + c;  and  a = c + b;  are both legal statements.
It doesn't require the b and c to be in any particular order.
Does this still bother you?

>I came to the conclusion that their grammer is not exactly Backus-Naur form.

Backus-Naur form uses <non-terminals>, terminals, and ::=.  For example:
<declaration> ::= declaration-specifiers init-declarator-list
<declaration> ::= declaration-specifiers
<declaration-specifiers> ::= <storage-class-specifier> <declaration-specifers>
<declaration-specifiers> ::= <storage-class-specifier>
<declaration-specifiers> ::= <type-specifier> <declaration-specifers>
<declaration-specifiers> ::= <type-specifier>
<declaration-specifiers> ::= <type-qualifier> <declaration-specifers>
<declaration-specifiers> ::= <type-qualifier>

Other constructs can carry exactly the same meaning, using more readable
notations.  Backus-Naur form does not require a grammar to be context-free,
to be unambiguous, or to have your strange property.  I don't think
anyone has ever named a kind of grammar that, for each valid input string,
would prevent all other permutations of that string from being valid.
And I'm sure that no one has named a kind of grammar that does that only
for some parts of some input strings.

-- 
Norman Diamond, Nihon DEC     diamond at tkou02.enet.dec.com
This is me speaking.  If you want to hear the company speak, you need DECtalk.