Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Tue, 03 Sep 2024 16:08:59 +0100
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <87a5gon59w.fsf@bsb.me.uk>
References: <vab101$3er$1@reader1.panix.com> <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> <87h6aytg7k.fsf@bsb.me.uk>
	<vb4blq$2rf0l$1@dont-email.me> <87jzfum66a.fsf@bsb.me.uk>
	<86ikvdphdl.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 03 Sep 2024 17:09:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2261761fd86fbbd2041e949d70d4d0c9";
	logging-data="3560687"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19tKElZqrg3jh9r8EpLLxDtEUx5tH1ZpKI="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:qSblIoIuoYSUZsiZp8x0nLrABes=
	sha1:9K6L3xCag7xz2aIan7KPb2ToyQ4=
X-BSB-Auth: 1.422acdf37c3a34e1c4c5.20240903160859BST.87a5gon59w.fsf@bsb.me.uk
Bytes: 3324

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben@bsb.me.uk> writes:
>
> [...]
>
>> And as for your remarks about typical implementations, does your C
>> parser /really/ accept an assignment expression on both sides of
>> an = operator?  What does that even look like in the code?  I have
>> written one C parser, contributed to one other and (over the
>> years) examined at least two more, and none of them do what you
>> seem to be suggesting is typical.
>
> It wouldn't be surprising to see a parser written so it would
> accept (syntactically) a superset of the well-formed inputs
> allowed by the language grammar.  Any parses not allowed by the
> grammar could then be flagged as erroneous in a later semantics
> pass.

Yes, that is pretty much what I've seen in more than one C parser.

I'm going to try to stop replying to Bart, partly because I think he
finds my replies annoying (so they are likely provoke unproductive
exchanges) but mainly because I am too literal.  His reply to me shows
that he parses C like most of the compilers I've seen -- accepting a
superset of valid LH sides (as you say) but not "exactly the same" the
syntax on both sides.  Recursive decent parses are inherently lopsided
in this respect because that's how they implement associativity.

> One reason to do this is to simplify error recovery in the face
> of syntax errors.  It's much easier to recover from a "correct"
> parse than from one that looks hopelessly lost.
>
> I'm not making any claim that such an approach is typical.  On
> the other hand it does seem to fit with some of the diagnostics
> given by gcc for inputs that are syntactically ill-formed.

-- 
Ben.