Bug #76826 [Fbk->Opn]: error: use of undeclared identifier 'finite'

From: Date: Tue, 16 Oct 2018 01:07:53 +0000
Subject: Bug #76826 [Fbk->Opn]: error: use of undeclared identifier 'finite'
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-217584@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76826&edit=1

 ID:                 76826
 User updated by:    php-bugs-2018 at ryandesign dot com
 Reported by:        php-bugs-2018 at ryandesign dot com
 Summary:            error: use of undeclared identifier 'finite'
-Status:             Feedback
+Status:             Open
 Type:               Bug
 Package:            Compile Failure
 Operating System:   Mac OS X 10.7.5
 PHP Version:        7.2.9
 Block user comment: N
 Private report:     N

 New Comment:

I am not a C++ programmer but from what I've been able to research, "finite" is an
old deprecated method of determining if a number is finite, and "isfinite" is its
replacement, available as of C99.

Given that, the PHP code used to make sense: It used to use "isfinite" if it was
available, and otherwise it would use "finite" if that was available. The change in
ad790bea2e4a8a25c79ceab964601f3785cd2bf1 seems wrong to me, because now, if compiling in C++11 mode
or newer, the newer "isfinite" method isn't used, and the deprecated
"finite" is used instead. Why would we want to use a deprecated function when a newer
replacement function is available, especially if we're compiling in a newer language mode?

The reason for the compile failure I reported appears to be that the intl extension uses icu, and
used icu-config --cxxflags to get the flags it should use. We're using icu 58.2 in
MacPorts, and it returns "--std=c++0x". (Yes, there is a typo: it should be one dash
instead of two, but the compiler still recognizes the flag despite that.) The intl extension was
changed in 4acc8500acd134dfab1a2ddb83aeb39fa1033abe on 9/28/2018 to always use C++11 mode regardless
what ICU says. So we're in C++11 mode and __cplusplus is 201103L which is why PHP is now trying
(misguidedly, in my opinion) to use "finite" here. I've also seen the same problem
when building the third-party swoole extension, which also uses C++11.

So why doesn't "finite" exist, even though HAVE_FINITE is 1? On Mac OS X 10.7,
/usr/include/math.h is just a wrapper that includes /usr/include/architecture/i386/math.h, and in
that file, the definition of "finite" and other deprecated functions is inside a block
which checks:

#if !defined( __STRICT_ANSI__) && !defined(_ANSI_SOURCE) &&
(!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE))

And it turns out that __STRICT_ANSI__ is defined (due, I believe, to requesting conformance to an
ISO C/C++ standard, in this case c++0x), therefore these legacy functions don't get defined. I
can get the build to succeed on 10.7 by undefining __STRICT_ANSI__ (e.g. by adding
"-U__STRICT_ANSI__" to CXXFLAGS), though I don't know what other implications that
might have elsewhere in the system headers so I don't think this is the solution we want to
use.

In OS X 10.8, Apple moved the header to /usr/include/math.h and rewrote it so that it only checks:

#if __DARWIN_C_LEVEL >= __DARWIN_C_FULL

__DARWIN_C_LEVEL is defined to be __DARWIN_C_FULL so on 10.8 and later old "finite" is
still available in strict ANSI mode.

As for why it also built successfully on 10.6, that's because on that system icu-config
--cxxflags returns nothing, because the old g++ 4.2.1 compiler on that system doesn't
have any C++11 support. Therefore we're not in strict ANSI mode, therefore the deprecated
functions are still defined.

I have tried reverting ad790bea2e4a8a25c79ceab964601f3785cd2bf1 and it builds successfully on 10.7,
and still builds fine on 10.13, despite the fact that the commit message for
ad790bea2e4a8a25c79ceab964601f3785cd2bf1 says that "isfinite" was supposed to have moved
into the std namespace as of C++11. Further research tells me that "isfinite" and friends
are only in the std namespace if you #include <cmath>. PHP doesn't do that; instead, it
includes the older <math.h>, in which case those functions are not in the std namespace. I
believe this confirms my suspicion that ad790bea2e4a8a25c79ceab964601f3785cd2bf1 doesn't do
anything useful and should be reverted.


Previous Comments:
------------------------------------------------------------------------
[2018-10-13 07:28:37] elis at hirwing dot se

@ab - I think the reason for the patch not applying was because the lines it tried to remove
wasn't there in that version of the source that it tried to patch. It also seems to differ
between 7.1.X and 7.2.X what they look like.

Make sure to take a copy of the log if you have use for it since it will go away. Nothing I can do
about that :/

Also, could you lend me some pointer to how to subscribe to this issue. I've tried several
times to fill email, solve math-problem and press subscribe but haven't got a single message.

------------------------------------------------------------------------
[2018-10-11 22:26:12] ab@php.net

@elis yep, that's the same bug. Thanks for re-posting the log. I've no Mac as well, so
only able to guess the conditions. With the patch - you need to ensure the -p option has the correct
level number, depending on the CWD when the patch gets applied. Alternatively you can edit the paths
in the patch, so they suffice for the build constellation.

Thanks.

------------------------------------------------------------------------
[2018-10-11 21:15:10] elis at hirwing dot se

@ab I've completely missed the answers here. I have tried to build 7.2.11 and 7.1.23 which have
failed the same way.

Too bad it's the same log viewer as before: https://logs.nix.ci/?key=nixos/nixpkgs.48228&attempt_id=94e95849-958b-4b83-8952-90bc4cf3021f
-- but it's the only way I have to get the log out from the darwin builds since I don't
have any darwin machines myself.

I've also tried to apply your patch on 7.2.11 and 7.1.23 for darwin, but it didn't apply
at all: https://logs.nix.ci/?key=nixos/nixpkgs.48228&attempt_id=7d415ce6-e908-439e-bbf4-5fe6797871c8

------------------------------------------------------------------------
[2018-10-05 07:13:21] ab@php.net

Thanks for the build new logs. Is that with the vanilla package? Were you able to play with the
condition as i've suggested? Perhaps you could try the patch i've just attached. I'd
be really reluctant to do fixes for EOL versions, but at least we could figure out what goes wrong
there. Probably only you can do that, as the chances to find someone with this OSX version are
probably marginal.

Thanks.

------------------------------------------------------------------------
[2018-10-05 07:09:59] ab@php.net

The following patch has been added/updated:

Patch Name: bug76826.poc.0.patch
Revision:   1538723399
URL:        https://bugs.php.net/patch-display.php?bug=76826&patch=bug76826.poc.0.patch&revision=1538723399

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=76826


--
Edit this bug report at https://bugs.php.net/bug.php?id=76826&edit=1


Thread (14 messages)

« previous php.bugs (#217584) next »