Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Abstract Syntax Tree for C programs Date: Thu, 13 Jun 2019 02:28:39 -0700 Organization: A noiseless patient Spider Lines: 43 Message-ID: <867e9p96m0.fsf@mailhub.linuxsc.com> 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> <86o9398slw.fsf@mailhub.linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="ef0a227b331df30b5055ba709176503b"; logging-data="3688"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+vulaXZIoRLiWJuTKT3KGXgZdU6tJkVJ8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:DxO1Cz6vsPlxHARZcQ1Yjyv785U= sha1:j9seELZyMJ9ZZz91GPQAZysFV0s= Xref: csiph.com comp.lang.c:144796 David Brown writes: > On 07/06/2019 14:52, Tim Rentsch wrote: > >> Keith Thompson writes: >> >>> "gcc -std=c11 -pedantic" warns that "ISO C forbids conversion of >>> object pointer to function pointer type". I believe that message is >>> incorrect. ISO C doesn't define the behavior of such a conversion, >>> but it doesn't forbid it (it doesn't violate a constraint or syntax >>> rule). [...] >> >> The Rationale document says this: >> >> 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. >> >> So I think gcc has it right, and clang has it wrong. > > It is reasonable to use the Rationale to judge what the Standards > authors intended, but it would appear here that they did not write > exactly what they intended. On the contrary, I think they did write what they intended. As I read the Standard, what it says is completely consistent with what is stated in the Rationale document. > Should the intention behind the standard, when expressed this > clearly, have more weight than the actual wording of the > standard? I think there's an assumption in that question, that what was written in the Standard is free of ambiguity. That's a bad assumption in this case. > Perhaps the answer is to be found in the defect reports? If > the authors did not write this clearly enough in the standards > (they are, after all, merely human) then there may be a defect > report covering it. There's nothing stopping you from looking to see if there is one.