Sujet : Re: Top 10 most common hard skills listed on resumes...
De : jameskuyper (at) *nospam* alumni.caltech.edu (James Kuyper)
Groupes : comp.lang.cDate : 31. Aug 2024, 21:04:57
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vavt19$14btp$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
User-Agent : Mozilla Thunderbird
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.
...
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.
Not correctly.
Given this:
>
x + y = z;
(x + y) = z;
>
My compiler produces the same AST for the LHS of '=' in both cases. I
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);
That is an invalid parse: the right operand of an addition expression
must be a multiplicative expression - y=z doesn't qualify. (y=z) would.
(x + y) = z;
That has a valid parse, but violates a constraint - x+y is not a
modifiable lvalue.
I'm surprised that the experts here are unsure about it.
I don't see uncertainty from those I consider experts. Kaz is saying
something about compensating for an incorrect parse by detecting the
problems after parsing rather than during parsing. I'd have to know a
lot of details about how the problem detection was performed to be sure
that it was safe. If it could be done, it would certainly be permitted -
the standard only requires that the final results are the same as if it
had been done the way the standard specifies. It much easier to evaluate
the validity of the design of a compiler when it parses things the way
the C standard specifies they should be parsed - but there might be
advantages to doing otherwise.