Sujet : Re: Top 10 most common hard skills listed on resumes...
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 01. Sep 2024, 04:04:20
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20240831195350.785@kylheku.com>
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 : slrn/pre1.0.4-9 (Linux)
On 2024-08-31, Bart <
bc@freeuk.com> wrote:
On 31/08/2024 23:31, Keith Thompson wrote:
Bart <bc@freeuk.com> writes:
[...]
Given this:
>
x + y = z;
(x + y) = z;
>
My compiler produces the same AST for the LHS of '=' in both cases.
[...]
If that's the case (and I don't doubt that it is), then your compiler is
not following the grammar specified by the ISO C standard. Since
`x + y` is not a unary-expression, `x + y = z` is not a syntactically
valid assignment expression.
>
Yet no compiler out of the dozen I tried reported a syntax error (except
SDCC).
That says exactly the same thing as, "Without carrying out an
extraordinary search, I've been able to confirm the existence of a
compiler that might actually be parsing the way the language is
specified, evidenced by it reporting a syntax error."
So what AST is produced by gcc, if any?
>
Most compilers, including mine, complain that an lvalue is expected.
Anyone using better parsing technology than what was available in 1970
will not be literally using the literal grammar in ISO C.
I can also say that the C grammar is buggy:
>
assignment-expression:
conditional-expression
unary-expression asssignment-operator assignment-expression
I second that. If I had energy and motivation for that sort of thing,
I would submit a defect report.
There is no value (no pun intended) in constraining the left side of an
assignment to just that class of expression that might produce a
modifiable lvalue, since that constraint must be checked regardless.
It creates an gratuitous inconsistency between the formal ISO C
grammar and the intuitive precedence model for expressions that everyone
understands. Even the K&R2 book has a precedence table (P. p53?).
When attempting to parse an assignment-expression, do you go for a
conditional-expression or unary-expression?
If using a parser generator tool, like one of the Yacc derivatives,
I would just make it:
expr : ... /* numerous rules */
| expr '=' expr { ... }
| ... /* numerous rules */
;
using %left and %right declarations to set up the operator
precedences and associativities.
Anything you do differently from a specification, though,
creates risk. It takes extra work to show that what you have
is equivalent.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca