Bug #73954 [Asn]: NAN check fails on Alpine Linux with musl

From: 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

« previous php.bugs (#206736) next »