On 2024-08-31, Bart <
bc@freeuk.com> wrote:
On 30/08/2024 21:41, Keith Thompson wrote:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:
Bart <bc@freeuk.com> writes:
I think that these (with x, y having compatible scalar types):
>
x + 1 = y;
(x + 1) = y; // in case above was parsed differently
>
are both valid syntax in C. It will fail for a different reason:
an '+' term is not a valid lvalue.
>
The compiler must tell you that neither is valid C. That's
because what is required on each side of assignment is not
exactly the same thing. It's a distraction to argue about why
each is not valid C as both have errors that require diagnostic
at compile time.
>
Bart is only saying that it's valid syntax, not that it's valid C.
>
According to the ISO C syntax (not taking into account contraints,
which are not syntax) that view is justified.
>
The second line is syntactically well-formed. The first line is
not.
Right, because the LHS of an assignment is a unary-expression.
`(x + 1)` can be parsed as a unary-expression, but `x + 1` cannot.
>
AFAICT both terms are parsed the same way.
Though they can be, it's not required by the ISO C gramamr.
>
Given this:
>
x + y = z;
(x + y) = z;
>
My compiler produces the same AST for the LHS of '=' in both cases. I
Sure, your compiler and others also. But this is not required.
According to the formal grammar in ISO C, this is bad syntax.
In terms of operator precedence (a concept not used in ISO C) we
can recognize the situation as similar to there being no defined
precedence between + and =, when they appear in that order:
E1 + E2 = E3. If there is no defined precedence, the situation
cannot be parsed.
Only in the order E1 = E2 + E3 does + have a higher precedence
than =, leading to the same abstract syntax as E1 = (E2 + E3).
The grammar production
assignment-expression: unary-expression assignment-op assignment-expression
doesn't admit parses where the left side is any of the intermediate
phrase structures between unary-expression and assignment-expression.
The grammar cannot derive any sentential forms that look like any
of these:
additive-expression assignment-op assignment-expression
multiplicative-expression assignment-op assignment-expression
inclusive-OR-expression assignment-op assignment-expression
etc. Any token sequence which matches these patterns is not
derivable by the grammar.
can't easily get the AST created by gcc. But the parsing of 'x + y = z'
has to be as one of these two:
>
x + (y = z);
(x + y) = z;
Yes, if we stipulate that:
- these operators are independent, binary operators; and
- there exists a defined precedence between them in that configuration
then there exists a parse, which is one of those two.
There are other possibilities, like:
- there doesn't exist a parse; or
- the two tokens constitute a ternary operator, and so the parse
produces an abstract syntax like this:
+ =
/ | \
x y z
I'm surprised that the experts here are unsure about it.
x + y = y simply does not match the grammar pattern rule "unary-expr op
assignment-expr". It is clear.
It's not necessary for ISO C compilers to follow the grammar that is
given in ISO C, as long as they implement all the requirements.
To show that a compiler is nonconforming, you have to show:
- incorrect input that fails to produce a required diagnostic, or
- correct input, but which does not produce the observable behavior that
is required of it, taking into account the implementation
characteristics.
A compiler which parses x + y = z as (x + y) = z is conforming,
as long as it produces the required diagnostic. Because (x + y)
isn't a modifiable lvalue, it is enough for that to be diagnosed,
and the requirement for a diagnostic is therefore met.
The diagnostic does not have to be "assignment requires unary
expression on the left"; the standard doesn't dictate the wording
of diagnostics. Semantically, only a unary expression can produce a
modifiable lvalue, so all is well.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca
Top 10 most common hard skills listed on resumes...
Re: Top 10 most common hard skills listed on resumes...