Re: Top 10 most common hard skills listed on resumes...

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.