Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Sat, 31 Aug 2024 20:26:31 -0700
Organization: None to speak of
Lines: 65
Message-ID: <871q243vh4.fsf@nosuchdomain.example.com>
References: <vab101$3er$1@reader1.panix.com> <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>
	<878qwc41g7.fsf@nosuchdomain.example.com> <86o758t6vd.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sun, 01 Sep 2024 05:26:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e33677cf1282cedfb021af5ed2609c95";
	logging-data="1306488"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/xsgSz5GG5DfZHA0jS5Dnb"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:Tzahkc1OCwjVXBuhR5fdE4gDgog=
	sha1:ibo427RxoGsD0pnSt1bXz8k2yaA=
Bytes: 4525

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Bart <bc@freeuk.com> writes:
> [...]
>>> 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.
>>> [...]
>>
>> [...] I'm skeptical that the C grammar is buggy.  [...]
>
> It appears that what Bart means by buggy is different from what
> you mean.  I think what Bart means is that the grammar is not
> suitable for being used by a particular parsing algorithm.  Of
> course that is not what the C standard means to supply, which is
> rules of grammar that exactly reflect what syntactic forms are
> suitable (syntactically) as C programs, without regard to how
> input source is processed.  The C standard's rules of grammar
> are meant as a declarative specification, not as a procedural
> description.  Bart's complaint is, I believe, a complaint that
> the grammar rules in the C standard do not provide a suitable
> procedural description (for the procedural framework he has in
> mind).  They aren't meant to.  Your comment is meant, I believe,
> to be about whether the grammar rules in the C standard provide
> an accurate declarative specification, which they almost
> certainly do, especially as regards to the limited area of
> expression syntax.

One data point: the yacc/bison grammar I cited upthread at
<https://gist.github.com/codebrainz/2933703>, which as far as I can
tell *is* meant as a procedural description, includes the following:

assignment_expression
    : conditional_expression
    | unary_expression assignment_operator assignment_expression
    ;

I haven't tested it beyond running `bison c99.y`, nor have I compared
the rest of c99.y (and c99.l) to the grammar in the standard.

I'm (still) skeptical that Bart has found a bug in the ISO C grammar
in any reasonable sense of the word "bug".

My impression at this point is that the ISO C grammar can be used
as-is to construct a working parser by a straightforward translation.
There are good reasons for not doing so (producing user-friendlier
error messages).  This is only an impression, and I could easily
be wrong.

I'll also note that you've discussed what you think Bart meant,
but not whether he's correct.

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