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: Thu, 06 Jun 2019 19:33:20 -0700 Organization: None to speak of Lines: 48 Message-ID: References: <87ftop38c1.fsf@bsb.me.uk> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="0d5b010e2076a714ee1f32c348b9a975"; logging-data="10732"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19VUyIFayR4qK78qvYWLxmO" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:BSmrLnZO8y+xA50FxLU/pzxVF/M= sha1:s+ZcZULr6CTEwOdUzuaddFYRJMY= Xref: csiph.com comp.lang.c:144559 James Kuyper writes: > On 6/6/19 8:43 PM, Keith Thompson wrote: >> James Kuyper writes: > ... >>> I've developed a general rule that has saved me from having to memorize >>> a lot of special cases, and from having to look up those cases I haven't >>> memorized: problems that can easily be diagnosed with certainty at >>> compile time tend to be constraint violations, not just undefined behavior. >>> >>> However, I misapplied that rule in this case. The void* could be a null >>> pointer, in which case the conversion would have well defined behavior: >>> the resulting function pointer is also null. Whether or not the void* is >>> null will often depend upon run-time events, and so cannot always be >>> diagnosed at compile time. Therefore the standard does not require that >>> it be diagnosed. >> >> A void*-to-function-pointer conversion is well defined only if the >> source is a null pointer *constant* (6.3.2.3p3). This: > > sigh - I'm making too many mistakes lately. > > 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. Perhaps because there are cases where it's actually useful -- dlsym() on POSIX systems, and probably similar features elsewhere. I wonder if the authors of the standard actually intended to leave the behavior undefined by omission. I'd be happier if the standard said *something* about such conversions, one way or the other. IMHO it would make sense to treat conversions of object pointers to function pointers or vice versa the same way we treat conversions of integers to pointers: An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation. We can convert a char value to a function pointer. Converting a void* to a function pointer makes at least as much sense. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */