Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Sun, 1 Sep 2024 03:04:20 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <20240831195350.785@kylheku.com>
References: <vab101$3er$1@reader1.panix.com> <vai1ec$2fns2$1@dont-email.me>
 <874j75zftu.fsf@bsb.me.uk> <valrj7$367a8$2@dont-email.me>
 <87mskwy9t1.fsf@bsb.me.uk> <vanq4h$3iieb$1@dont-email.me>
 <875xrkxlgo.fsf@bsb.me.uk> <vapitn$3u1ub$1@dont-email.me>
 <87o75bwlp8.fsf@bsb.me.uk> <vaps06$3vg8l$1@dont-email.me>
 <871q27weeh.fsf@bsb.me.uk> <20240829083200.195@kylheku.com>
 <87v7zjuyd8.fsf@bsb.me.uk> <20240829084851.962@kylheku.com>
 <87mskvuxe9.fsf@bsb.me.uk> <vaq9tu$1te8$1@dont-email.me>
 <875xrivrg0.fsf@bsb.me.uk> <20240829191404.887@kylheku.com>
 <86cylqw2f8.fsf@linuxsc.com> <871q2568vl.fsf@nosuchdomain.example.com>
 <vavmbk$13k4n$1@dont-email.me> <87cylo494u.fsf@nosuchdomain.example.com>
 <vb09gd$16mr5$1@dont-email.me>
Injection-Date: Sun, 01 Sep 2024 05:04:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0e034b13bfff277bc16b176d591cb6d2";
	logging-data="1441391"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19vhs/YWRUQ+w8pbFlkhhgrxAHyKhjNNa0="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:5j6s1W4odbjuyVwxAH2uH/43Mys=
Bytes: 4173

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/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca