Path: ...!news.nobody.at!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: Fri, 30 Aug 2024 06:40:14 -0700
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <86h6b2w2m9.fsf@linuxsc.com>
References: <vab101$3er$1@reader1.panix.com> <vaf7f0$k51$2@reader1.panix.com> <vafgb2$1to4v$2@dont-email.me> <92ab79736a70ea1563691d22a9b396a20629d8cf@i2pn2.org> <vafim7$1ubg8$1@dont-email.me> <vah4hr$2b9i8$5@dont-email.me> <vahngt$2dtm9$1@dont-email.me> <87r0abzcsj.fsf@bsb.me.uk> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Fri, 30 Aug 2024 15:40:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e18e7e841c3e455d36004383aa145572";
	logging-data="555522"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19shaqDlRqdCDbtQX1ac4MfoQ5u+e6SObs="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:RkjZ407PWTI1IDtdSzuNo+JFUdA=
	sha1:eCKk+njCYJYp2wfyb+Yvqevg9qA=
Bytes: 4174

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

> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:

[.. is assignment in C symmetric w.r.t. the two sides of '=' ..]

>> Have you taken Bart's bait and are now discussing a narrower
>> context?
>>
>> The claim that C's assignment is symmetric and what is required on
>> the two sides is exactly the same is junk.  C's assignment has
>> different syntax on each side, and what is required is even more
>> strict.
>
> In the ISO C grammar for assignment, there is a "unary expression"
> on the left and an "assignment expression" on the right.  That's
> just a particular factoring of the grammar that implementors don't
> have to follow, if the correct results are produced.
>
> Under a parser generator tool we could have a production rule like
> expr '=' expr , where the '=' token has an elsewhere-declared
> associativity and precedence.
>
> The basic idea that the same syntactic kind of thing is on both
> sides of a C assignment (with an additional lvalue constraint) is
> valid;  it's just not literally true if we are discussing the
> details of how ISO C expresses the grammar.

I think this kind of reasoning is more harmful than helpful.  The
point of the discussion is to understand what the ISO C standard
requires.  Constraints apply only in the context of a complete
parse of a syntactically well-formed translation unit.  To give
an example:

    enum { A = 47 };

    int
    foo( int x ){
        int A = 23;
        return  x+A;
    }

There is nothing wrong with this translation unit.  But if we
look at just the 'A = 23' as an assignment expression, it
violates a constraint.  Reasoning about how an implementation
might go about parsing its input might lead one astray as to
how compilers are allowed to behave.

Of course implementations are allowed to phrase diagnostics in
any way they choose, even when a diagnostic is required.  But for
understanding what the C standard mandates, it's better not to
think about how the parsing might be done, and instead follow the
given easy-to-understand guideline, namely, that constraints
apply only in the context of a complete parse of a syntactically
well-formed translation unit.  If a translation unit is not
syntactically well-formed then no further consideration is needed
because it already doesn't comply with the C standard's rules;
it's only when a translation unit is completely syntactically
well-formed that one needs to think about constraint violations
and whether constraints are violated.