Path: csiph.com!usenet.pasdenom.info!news.gegeweb.eu!gegeweb.org!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: "...the value becomes,indeterminate each time the declaration is reached" Date: Mon, 25 Feb 2019 14:06:55 -0800 Organization: A noiseless patient Spider Lines: 41 Message-ID: <86ftsbed4w.fsf@mailhub.linuxsc.com> References: <4c59dca0-2449-4234-a935-b6d604088caf@googlegroups.com> <84b47866-600b-48d2-85b6-1538f19b00df@googlegroups.com> <0953b1d5-c0c3-4d49-82a3-ecc516b1b19a@googlegroups.com> <30065f8f-0b5b-4d17-846f-4fa63051cd0e@googlegroups.com> <9d6896dc-a369-4eb0-a93c-c0317a19908e@googlegroups.com> <87tvhfe5ls.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="0b225037cf1357b33e38b5d7f82ed86f"; logging-data="4073"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX183KyofD93ZCewSbEsWn8m/RpOGpAnzuao=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:NmadYmY24d1g2CEHsdvqsnR04C8= sha1:MdIz0IK9Ln6X6xgUsEvvYHAn08g= Xref: csiph.com comp.lang.c:141354 Ben Bacarisse writes: > Keith Thompson writes: > >> David Brown writes: >> [...] >> >>> There are some kinds of UB that could be handled by a more complex >>> grammar describing the C language. The grammar rules of C /could/ >>> have precluded invalid multi-byte characters in the source code, >>> or converting a pointer to something other than an integer or >>> pointer type. But they don't preclude them. If they had, then >>> there would be no need to call them "undefined behaviour" - the >>> code would simply not be syntactically valid C. >> >> [...] >> >> I don't think pointer conversion is an example of what you're >> talking about. Converting a pointer to something other than an >> integer or pointer type is a constraint violation. I don't see how >> that could be enforced in the grammar. Given: >> >> some_type x = (some_other_type)y; >> >> we can't tell whether the constraint is violated without knowing >> how some_time and some_other_type are defined. > > Since every constraint violation is checkable at compile time, > there will be some grammar that will only parse C programs with no > such violations. It will almost certainly be impractical, not > context-free and require an exponential-time algorithm to parse, > but I think I am right in saying that such a grammar exists. Such a grammar certainly exists. It will certainly not be context free, but need not be exponential and may even be practical, in much the same way that LALR grammars are a useful subset of general context-free grammars. It's only when we want to exploit the full generality of context-sensitive grammars (or even context-free grammars for that matter) that such problems are inescapable. A grammar for C doesn't need that much power - it can get by on a limited subset that is more tractable.