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 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: <875xrkxlgo.fsf@bsb.me.uk> <87o75bwlp8.fsf@bsb.me.uk> <871q27weeh.fsf@bsb.me.uk> <20240829083200.195@kylheku.com> <87v7zjuyd8.fsf@bsb.me.uk> <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk> <875xrivrg0.fsf@bsb.me.uk> <20240829191404.887@kylheku.com> <86cylqw2f8.fsf@linuxsc.com> <871q2568vl.fsf@nosuchdomain.example.com> <87cylo494u.fsf@nosuchdomain.example.com> <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 writes: > Keith Thompson writes: >> Bart 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 , 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 */