error in code

[Nisse Engström]

It's a syntax error. An initializer is either an initializer-list
enclosed in curly braces (possibly followed by a final comma),
or an assignment-expression. ``2.2, 4.2, 5.00'' is not an
assignment-expression.

The comma operator is parsed right-to-left. The expression
``double a[] = 2.2, 4.2, 5.00'' contains three assignment-
expressions: ``5.00'', ``4.2'' and ``double a[] = 2.2''.

/Nisse

 

[Tim Rentsch]

Le 28/05/11 21:28, Bill Cunningham a @C3{A9}crit :
double a[] = 2.2, 4.2, 5.00;
...
p.c: In function `main':
p.c:12: invalid initializer
p.c:12: parse error before numeric constant

...lcc-win issued NO ERRORS AT ALL.

Even if you claimed conformance, it's not required to. It
follows the context free grammar. [snip]

Sure looks like a syntax error to me. You have a
derivation to offer?

I also think it's a syntax error, but take a look at this more subtle case:

int i=1, j=2;

int main(void)
{
int a[] = i, j;
}

It's invalid because the array initializer doesn't have braces. But that's
not a requirement of the grammar. In n1256.pdf, the clause that it violates
is 6.7.8.16, under the heading of "Semantics", not "Constraints".

And it can be made valid by putting braces around just the i, which makes a
single-element a[] and a local j shadowing the global j:
int a[] = {i}, j;
or by putting braces around both, making a 2-element a[]:
int a[] = {i, j};

A compiler that accepts the form without braces must be choosing one of those
interpretations. Which one?

If no diagnostic message is issued, the first one.

 

[Keith Thompson]

(e-mail address removed) (Alan Curry) writes: [...]

I also think it's a syntax error, but take a look at this more subtle case:

int i=1, j=2;

int main(void)
{
int a[] = i, j;
}

It's invalid because the array initializer doesn't have braces. But that's
not a requirement of the grammar. In n1256.pdf, the clause that it violates
is 6.7.8.16, under the heading of "Semantics", not "Constraints".

And it can be made valid by putting braces around just the i, which makes a
single-element a[] and a local j shadowing the global j:
int a[] = {i}, j;
or by putting braces around both, making a 2-element a[]:
int a[] = {i, j};

A compiler that accepts the form without braces must be choosing one of those
interpretations. Which one?

If no diagnostic message is issued, the first one.

How do you arrive at that conclusion?

If no diagnostic message is issued, the compiler is non-conforming.

 

[Tim Rentsch]

(e-mail address removed) (Alan Curry) writes: [...]

I also think it's a syntax error, but take a look at this more subtle case:

int i=1, j=2;

int main(void)
{
int a[] = i, j;
}

It's invalid because the array initializer doesn't have braces. But that's
not a requirement of the grammar. In n1256.pdf, the clause that it violates
is 6.7.8.16, under the heading of "Semantics", not "Constraints".

And it can be made valid by putting braces around just the i, which makes a
single-element a[] and a local j shadowing the global j:
int a[] = {i}, j;
or by putting braces around both, making a 2-element a[]:
int a[] = {i, j};

A compiler that accepts the form without braces must be choosing one of those
interpretations. Which one?

If no diagnostic message is issued, the first one.

How do you arrive at that conclusion?

Because if 'j' is part of the initializer for 'a[]' rather than a
separate declarator there is a syntax violation.

If no diagnostic message is issued, the compiler is non-conforming.

Did you miss Alan Curry's comment? The missing braces around {i}
is only undefined behavior, not a constraint violation, and there
is no syntax violation.

I should acknowledge that the UB here actually does grant
sufficient freedom to permit the second interpretation. However,
any implementation that knowingly provides an extension to omit
the braces for array initializers would be rather perverse in
making that choice, going as does against the grain of the
syntactic analysis necessary to avoid a diagnostic.

 

[Keith Thompson]

(e-mail address removed) (Alan Curry) writes: [...]
I also think it's a syntax error, but take a look at this more subtle case:

int i=1, j=2;

int main(void)
{
int a[] = i, j;
}

It's invalid because the array initializer doesn't have braces. But that's
not a requirement of the grammar. In n1256.pdf, the clause that it violates
is 6.7.8.16, under the heading of "Semantics", not "Constraints".

And it can be made valid by putting braces around just the i, which makes a
single-element a[] and a local j shadowing the global j:
int a[] = {i}, j;
or by putting braces around both, making a 2-element a[]:
int a[] = {i, j};

A compiler that accepts the form without braces must be choosing one of those
interpretations. Which one?

If no diagnostic message is issued, the first one.

How do you arrive at that conclusion?

Because if 'j' is part of the initializer for 'a[]' rather than a
separate declarator there is a syntax violation.

If no diagnostic message is issued, the compiler is non-conforming.

Did you miss Alan Curry's comment? The missing braces around {i}
is only undefined behavior, not a constraint violation, and there
is no syntax violation.

You're right.

And I think I see some sloppy wording in 6.7.8.16p13:

The initializer for a structure or union object that has
automatic storage duration shall be either an initializer list
as described below, or a single expression that has compatible
structure or union type. In the latter case, the initial value of
the object, including unnamed members, is that of the expression.

But an initializer-list doesn't include the '{' and '}' delimiters.
For example, given
struct foo obj = { 10, 20 };
the initializer-list is ``10, 20'', *not* ``{ 10, 20 }''. p13 seems
to be referring to ``{ 10, 20 }'' as an "initializer list".

I should acknowledge that the UB here actually does grant
sufficient freedom to permit the second interpretation. However,
any implementation that knowingly provides an extension to omit
the braces for array initializers would be rather perverse in
making that choice, going as does against the grain of the
syntactic analysis necessary to avoid a diagnostic.

Which makes me wonder why the standard didn't just make it a
constraint violation.

 

[Tim Rentsch]

Which makes me wonder why the standard didn't just make it a
constraint violation.

Speculating: to tolerate some pre-ANSI implementations
without forcing conforming implementations to have to
accept omitting the braces in such cases. (There are
other plausible reasons but this one seems to me the
most probable.)

 

[jacob navia]

Le 03/06/11 03:10, Tim Rentsch a écrit :

Speculating: to tolerate some pre-ANSI implementations
without forcing conforming implementations to have to
accept omitting the braces in such cases. (There are
other plausible reasons but this one seems to me the
most probable.)

The bug I had was just in the absence of a diagnostic...
The compiler assumed it had seen an opening brace and
everything worked up to the ";". Since it never saw
the opening brace, braces weren't unbalanced and it did
not complain either at the end of the construct.

This bug was introduced in the context of my efforts
to implement the C99 array initialization.

 

[Tim Rentsch]

Le 03/06/11 03:10, Tim Rentsch a @C3{A9}crit :

The bug I had was just in the absence of a diagnostic...
The compiler assumed it had seen an opening brace and
everything worked up to the ";". Since it never saw
the opening brace, braces weren't unbalanced and it did
not complain either at the end of the construct.

This bug was introduced in the context of my efforts
to implement the C99 array initialization.

That seems strange since the earlier posted example
is a syntax error in both C99 and C90.

 

[jacob navia]

Le 04/06/11 04:37, Tim Rentsch a écrit :

That seems strange since the earlier posted example
is a syntax error in both C99 and C90.

Yes, but I commented out the call to
error("Missing opening brace");

Why did I do that in 2008?

I do not remember, but I was doing the C99 array initialization
stuff, and I may have commented out two lines instead of one,
who knows.

Some bugs are really difficult to figure out, mostly because you
just did NONSENSE you see?