Path: ...!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: Mon, 02 Sep 2024 20:04:38 -0700
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <86ikvdphdl.fsf@linuxsc.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> <87h6aytg7k.fsf@bsb.me.uk> <vb4blq$2rf0l$1@dont-email.me> <87jzfum66a.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 03 Sep 2024 05:04:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5dc3c968fdc353e2fd687882edf89fc4";
	logging-data="3360519"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/YTk/FmxFMM3AJOTM+I/PMGmv0ouWNYTc="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:KvEdMv25MjStHwQnxwwj+efPNbk=
	sha1:1eJ3JgF1KJjmYEx5L2QA/VcZRsg=
Bytes: 2602

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.

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.