Re: Top 10 most common hard skills listed on resumes...

Bart <bc@freeuk.com> writes:

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).
>
So what AST is produced by gcc, if any?

I don't know.

Most compilers, including mine, complain that an lvalue is expected.

Presumably you know what grammar your compiler uses.  Feel free to
comment on it, particularly on whether it follows the grammar specified
in the C standard.

A parser that strictly follows the ISO C grammar would reject
(diagnose, flag, whatever) `x + y = z;` just as it would reject `x = y +;`.

>
Which one does that (apart from SDCC)?

I don't know.

It is interesting to know (as I've confirmed) that SDCC produces
different error messages for the two cases, suggesting that it uses a
grammar that more closely follows what's defined in the standard.

$ cat foo.c
void func(void) {
    int n;
    (n + 1) = 42;
}
$ sdcc -c foo.c
foo.c:3: error 10: 'lvalue' required for 'assignment' operation.
$ cat bar.c
void func(void) {
    int n;
    n + 1 = 42;
}
$ sdcc -c bar.c
bar.c:3: syntax error: token -> '=' ; column 11
$

This is an observation, not a complaint.  It doesn't imply that your
compiler is non-conforming or buggy.  A parser that doesn't strictly
follow the ISO C grammar could still be part of a conforming compiler.
 

>
I can also say that the C grammar is buggy:
>
    assignment-expression:
        conditional-expression
        unary-expression asssignment-operator assignment-expression
>
When attempting to parse an assignment-expression, do you go for a
conditional-expression or unary-expression?
>
The latter is a subset of the former. If you go for a
conditional-expression and find that an assignment-operator follows,
now you have to perform some analysis on the LHS to see if that
conditional-expression contains only a unary-expression.
>
However, if it's not a unary-expression, it will fail for other reasons
anyway, because all those other things that a conditional-expression
will be, can't be lvalues.
>
That also applies to many unary-expressions, such as 42, or a++; those
can't be lvalues either, even though the syntax is valid.
>
So it makes sense to do only an lvalue test.

I'm not saying it doesn't.  Using a more permissive grammar can be
useful for catching certain errors and issuing more meaningful
diagnostics.

I'm skeptical that the C grammar is buggy.  The only ambiguity I'm aware
of is that recognizing typedef names requires feedback from the symbol
table.  I haven't analyzed this particular case, and it's been a long
time since I've done any serious work with parsers, but I'd be surprised
if you've found a longstanding bug.  (Congratulations if you have.)

Perhaps others can weigh in.  There's a C99 yacc/bison grammar here:

https://gist.github.com/codebrainz/2933703

I might play with it later.  (bison reports one shift/reduce conflict; I
think it's related to if/else.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */