On 21/01/20 21:50 -0300, Alexandre Oliva wrote:
On Jan 3, 2020, Jonathan Wakely <jwak...@redhat.com> wrote:
+#include <math.h>
+#ifdef HAVE_IEEEFP_H
+# include <ieeefp.h>
+#endif
+], [
+ void (*f)(void) = (void (*)(void))$1;
I wondered whether using ($1) here instead of just $1 would give any
benefit. It would mean that function-like macros are ignored.
The lack of parentheses after a functional macro name is enough to avoid
its use as a macro. However, the test I used wouldn't avoid aliasing
macros, such as #define foo bar, and it would pass even if the name was
defined as an object rather than as a function.
I've also come up with a way to test, during C compilation, that $1 is a
function rather than anything else.
If the test was in C++, we could presumably use template type resolution
and static asserts to recognize function-typed expressions, though a
possibility of overloading could make it fall apart.
In theory the closer we are to the environment in which the test result
will be used, the more likely we are to get the desired result, but I'm
a little concerned about switching to a C++ test, precisely because of
the math.h header that we might or might not override, and of unexpected
overloading that system math headers might offer if they are C++-ready,
which could then get us wrong test results. Any thoughts on this
possibility?
Meanwhile, here's what I'm testing now...
It's supposed to be a strict incremental improvement, unless $1-&$1
unexpectedly compiles for some case I couldn't think of.
Isn't allowing arithmetic on function pointers a GNU extension? It
gets diagnosed with -pedantic.
I think just adding the #undef to what you had originally is the best
version.
