Path: ...!feeds.phibee-telecom.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: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Sun, 01 Sep 2024 13:07:35 -0700
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <86mskrrvco.fsf@linuxsc.com>
References: <vab101$3er$1@reader1.panix.com> <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> <20240831195350.785@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 01 Sep 2024 22:07:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1ccc4d5fef9c2c82c9c978d9286151e6";
	logging-data="1702070"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19xa1BaGJCRwkdhIgoF1o83nPws4TgIaB0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:EuFW9/+dvTR7hgF6HwkOF0SmVbc=
	sha1:AuPTXEtWevNxu7RTVorZEwnzfrA=
Bytes: 3934

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> On 2024-08-31, Bart <bc@freeuk.com> wrote:
[...]
>> 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.

This idea is totally wrongheaded.  The most important purpose of
the ISO C standard is to be read and understood by ordinary C
developers, not just compiler writers.  The grammar in the C
standard is both easy to understand and a precise and accurate
specification for what syntax is accepted.  Furthermore it is
written in a way that doesn't encourage any particular parsing
technology, which is definitely a benefit, because it promotes
looking at alternate approaches.  On the last point, it is much
more important that developers be able to tell when a compiler
is doing things wrong than it is for compiler writers to be
sure they have met a specification, because if it is the
slightest bit difficult for developers then they will start to
rely on compilers as the ultimate authority rather than the C
standard itself, which is a very bad thing.