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 12:09:32 -0700 Organization: None to speak of Lines: 57 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="0ad8b66ef2f1a8fe8c740ae2f33d0263"; logging-data="1082"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/jVLRf8l5u47wQH/wT8Nm9" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:yRevcR8tmmvD5XyC38ojZhOSTKQ= sha1:faI3Zkhew4M8F0k6jhLzKGOSDNg= Xref: csiph.com comp.lang.c:144539 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. gcc, incorrectly IMHO, treats it as a constraint violation (and I've reported that as a bug). clang, for example, does not. Still, if you're using gcc, you have to deal with that (which means, for example, that you can't use -pedantic-errors). > However, selecting POSIX should guarantee that the result, after issuing > that diagnostic, is an executable that is guaranteed to behave in the > way mandated by POSIX, despite the fact that C itself provides no such > guarantee. > > There aren't many modern machines where object pointers are too small to > hold function pointer values - such a machine would necessarily be a > non-POSIX system. I've no idea whether gcc has or even can be ported to > such a machine. If so, I wonder what would happen if you compiled such > code with those options. Would if fail to compile, or would it produce > an executable that failed to conform to POSIX requirements for such code? You could have dlsym() return a special value (of type void*, but perhaps not really a pointer), and have the compiler treat a void* to function pointer conversion specially. The void* value returned by dlsym() for a function might encode an index into a table of function pointers, for example -- or it could be a composite value consisting of an index into a table of dynamic libraries and an index into a table of function pointers for that library. Remember that converting a void* value to a function pointer is require to work *only* for values returned by dlsym(). -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */