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: Abstract Syntax Tree for C programs Date: Fri, 07 Jun 2019 10:33:27 -0700 Organization: None to speak of Lines: 63 Message-ID: References: <98193656-76f0-4718-9a97-a24ba0aa9b7c@googlegroups.com> <4ff90bb7-33e5-4dcd-828f-b0d40f237420@googlegroups.com> <8a72685f-2774-4187-98bf-c9ecd44b3240@googlegroups.com> <6ed2dfc1-a737-4fb3-b59a-3aa1c337061d@googlegroups.com> <86pnnp8snc.fsf@mailhub.linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="0d5b010e2076a714ee1f32c348b9a975"; logging-data="12759"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/17qTeMsrdFx4iLPvCixJV" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:xzGgaD9+a5JWW6QAUtIA3mce560= sha1:qflWia0hulR9gI+k4RopfRSeh50= Xref: csiph.com comp.lang.c:144607 Tim Rentsch writes: > James Kuyper writes: [...] >> As a result, this is actually easily diagnosable at compile time, and >> thus I would have expected it to be a constraint violation - which >> leaves me wondering why it isn't. [Context: "this" is a cast of a void* value to a function pointer type or vice versa.] > The Rationale document says this: > > Consequences of the treatment of pointer types in the > Standard include: > [...] > * Even with an explicit cast, it is invalid to convert a > function pointer to an object pointer or a pointer to > void, or vice versa. [...] > > Note the third-to-last item. It seems clear the authors intended > that converting between function pointer types and object pointer > types is not just undefined behavior but simply never allowed in > accepted C code. The word "invalid" is ambiguous. It's not defined anywhere as far as I can tell, and just a few paragraphs down it's clearly used in a context that does not refer to something that violates a constraint or a syntax rule: Regardless how an invalid pointer is created, any use of it yields undefined behavior. The standard has several well defined terms for various kinds "invalid" code (syntax errors, constraint violations, undefined behavior, unspecified behavior, etc.). It's too bad that part of the rationale didn't use one of them. Surely converting a char value to void* (in an implementation where sizeof(void*)>1) is equally "invalid", but the language clearly permits it. Meanwhile, the wording in the standard seems unambiguous to me: casting a void* value to a function pointer type does not violate any constraint or syntax rule, but its behavior is not defined. The standard very clearly says that behavior that is not defined is undefined behavior. I can believe that the unambiguous wording of the standard does not reflect the intent, but it's unreasonable to expect users of the standard to infer that the intent contradicts the words. And I suspect that many members of the committee are familiar with dlsym() and would not want to make it impossible to use without violating a constraint. (A personal note: Tim, you're still in my killfile, but that fact doesn't place any obligations on me.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */