Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: "...the value becomes,indeterminate each time the declaration is reached" Date: Thu, 07 Feb 2019 16:35:55 -0800 Organization: None to speak of Lines: 48 Message-ID: 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="e2fe68fc85715b1ccf6893e6346d7d34"; logging-data="29752"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+HtbisOkHnheAGg6nnQZCb" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:mr9wZRHAzrPiG2fxxZjCI9MD+BM= sha1:/u6qabQCR3vbVUoq03hKqfBU9Vo= Xref: csiph.com comp.lang.c:140753 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. Hmm, perhaps my concept of "grammar" is too narrow. Certainly the grammar in Annex A of the standard couldn't resolve whether the above assignment is type-consistent. (And as others have pointed out, typedefs introduce some conceptual problems.) Are you thinking of an "attribute grammar"? https://en.wikipedia.org/wiki/Attribute_grammar > Even so, as I think you will agree, talking about grammars for C that > are not what's in Appendix A of the standard is just going to sow > confusion. And MM's more general remark that a program with UB being > "ungrammatical" (the scare quotes are his and note worthy) is just > baffling. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */