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.

Ok to install?


reject macros in math decl check

From: Alexandre Oliva <ol...@adacore.com>

The C++ headers #undef the functions we are testing for, just in case
they're implemented as macros.  Do that as well, so as to reject
macros of the form #define foo bar, where bar is the actual
implementation, since those wouldn't work in C++ after the #undef.

While at that, tighten the test so that it doesn't take objects of
pointer types as if they were functions.


for  libstdc++-v3/ChangeLog

        * crossconfig.m4 (GLIBCXX_CHECK_MATH_DECL): Reject macros and
        data objects.
        * configure: Rebuild.
---
 configure      |   66 +++++++++++++++++++++++++++++++++++++-------------------
 crossconfig.m4 |   11 ++++++++-
 2 files changed, 54 insertions(+), 23 deletions(-)

diff --git libstdc++-v3/crossconfig.m4 libstdc++-v3/crossconfig.m4
index 2a0cb04..221b59d 100644
--- libstdc++-v3/crossconfig.m4
+++ libstdc++-v3/crossconfig.m4
@@ -322,6 +322,14 @@ dnl argument 1 is name of function to check
 dnl
 dnl ASSUMES argument is a math function
 dnl
+dnl Test for $1 - &$1: it's well-formed iff $1 names a function,
+dnl because $1's type decays to that of &$1.
+dnl For any object type, even arrays and void*, types won't match.
+dnl
+dnl Undefine $1, so that we don't accept an alias macro, e.g.
+dnl say define foo bar, when bar is the function.  Our C++ headers
+dnl undefine math function names, so such a macro wouldn't do.
+dnl
 dnl GLIBCXX_CHECK_MATH_DECL
 AC_DEFUN([GLIBCXX_CHECK_MATH_DECL], [
   AC_CACHE_CHECK([for $1 declaration],
@@ -333,8 +341,9 @@ AC_DEFUN([GLIBCXX_CHECK_MATH_DECL], [
 #ifdef HAVE_IEEEFP_H
 # include <ieeefp.h>
 #endif
+#undef $1
 ], [
-  void (*f)(void) = (void (*)(void))$1;
+  (void)($1 - &$1);
 ], [glibcxx_cv_func_$1_use=yes
 ], [glibcxx_cv_func_$1_use=no])])
   if test "x$glibcxx_cv_func_$1_use" = xyes; then


-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist           Stallman was right, but he's left :(
GNU Toolchain Engineer    FSMatrix: It was he who freed the first of us
FSF & FSFLA board member                The Savior shall return (true);

Reply via email to