Bug #73954 [Asn]: NAN check fails on Alpine Linux with musl
| From: | cmb@php.net | Date: | Wed, 18 Jan 2017 23:00:26 +0000 |
| Subject: | Bug #73954 [Asn]: NAN check fails on Alpine Linux with musl | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-206736@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=73954&edit=1
ID: 73954
Updated by: cmb@php.net
Reported by: zaq178miami at gmail dot com
Summary: NAN check fails on Alpine Linux with musl
Status: Assigned
Type: Bug
Package: *General Issues
Operating System: Alpine Linux
PHP Version: Irrelevant
Assigned To: ajf
Block user comment: N
Private report: N
New Comment:
> I can look into it, but it works for me.
See <https://3v4l.org/PHBQK>. Why does Z_PARAM_LONG
accept NAN,
but a userland
int type declaration does not?
The different behavior with musl[1] would have been to be resolved
also, but I have some doubts that the test script in the OP should
really have the reported expected result, especially when
considering
> [â¦], but typehints for userland and internal functions inherit
> their handling of NaN for integer parameters from ZPP (and
> actually share the code for this with ZPP internally), [â¦]
[1] <https://www.musl-libc.org/>
Previous Comments:
------------------------------------------------------------------------
[2017-01-18 00:45:32] alex dot masterow at gmail dot com
> So, what particular OS, compiler and version are you dealing with?
Alpine Linux (alpine:3.5/edge on Docker hub)
$ uname -a
Linux version 3.16.0-4-amd64
musl 1.1.16-r2
gcc 6.3.0-r1
php 7.0.14/15
------------------------------------------------------------------------
[2017-01-17 23:06:00] ajf@php.net
I can look into it, but it works for me. So, what particular OS, compiler and version are you
dealing with?
------------------------------------------------------------------------
[2017-01-17 23:01:54] cmb@php.net
It seems to me that the NaN handling is broken (not only with
musl). Andrea, could you please take a closer look at this?
------------------------------------------------------------------------
[2017-01-17 20:58:56] alex dot masterow at gmail dot com
> OP, could you see if is_nan(NAN) returns TRUE?
It returns FALSE.
> are you certain NAN is actually a NaN? Could you try var_dump(NAN);?
float(NAN)
The same output as documentation is_nan().
------------------------------------------------------------------------
[2017-01-17 20:31:50] ajf@php.net
zend_isnan is defined in https://github.com/php/php-src/blob/db894fa6aa6e98811bcc39b1331fc201e33c10ef/Zend/configure.in#L72-L80:
#ifndef zend_isnan
#ifdef HAVE_ISNAN
#define zend_isnan(a) isnan(a)
#elif defined(HAVE_FPCLASS)
#define zend_isnan(a) ((fpclass(a) == FP_SNAN) || (fpclass(a) == FP_QNAN))
#else
#define zend_isnan(a) 0
#endif
#endif
That last one doesn't look like a safe default. I wonder if it's falling back to that.
((a)!=(a)) would be a safer default.
OP, could you see if is_nan(NAN) returns TRUE?
On the same note, are you certain NAN is actually a NaN? Could you try var_dump(NAN);? I am
wondering if I possibly broke that constant a little while ago.
------------------------------------------------------------------------
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=73954
--
Edit this bug report at https://bugs.php.net/bug.php?id=73954&edit=1