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 17:43:31 -0700 Organization: None to speak of Lines: 55 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="12218"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+gUD4ftanIs6pOJRW3RLLE" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:5MBuD8oCT1cbH4lPxtoOG8Yo4dU= sha1:32i17ofDAPVZJB+eBMgYA76/+JU= Xref: csiph.com comp.lang.c:144555 James Kuyper writes: > On 6/6/19 3:09 PM, Keith Thompson wrote: >> James Kuyper writes: >>> On 6/5/19 10:06 PM, Keith Thompson wrote: >>>> James Kuyper writes: >>>>> On 6/5/19 7:09 PM, Keith Thompson wrote: >>>>> ... >>>>>> rule). But if you're writing code that depends on POSIX features, >>>>>> you're probably not going to use "-std=c11 -pedantic". >>>>> >>>>> But you might use >>>>> >>>>> -std=c11 -pedantic -D_POSIX_C_SOURCE=200809L >>>> >>>> I still get the warning, and using "-std=gnu11" doesn't turn it off: >>> >>> Sorry - I should have been clearer - I was only addressing the issue of >>> what options a gcc user would select when relying upon POSIX features. I >>> didn't think to test whether it would prevent this diagnostic, but I'm >>> not surprised that it fails to prevent it. This is a constraint >>> violation, so a diagnostic is mandatory, and -pedantic requests that all >>> mandatory diagnostics be produced. >> >> In my opinion converting a void* to a function pointer is *not* a >> constraint violation. If you think it is, please cite the constraint >> that it violates. > > You're right. It's undefined behavior "by omission of any explicit > definition of the behavior", not a constraint violation. > > 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: void *null_pointer_but_not_constant = 0; void (*function_pointer)(void) = (void(*)(void))null_pointer_but_not_constant; has undefined behavior (and gcc treats it as a constraint violation). -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */