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

Edit report at https://bugs.php.net/bug.php?id=73954&edit=1 ID: 73954 Updated by: ajf@php.net Reported by: zaq178miami at gmail dot com Summary: NAN check fails on Alpine Linux with musl Status: Feedback Type: Bug Package: *General Issues Operating System: Alpine Linux PHP Version: Irrelevant Assigned To: cmb Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2017-01-17 20:26:03] ajf@php.net Specifically, ZPP and type declarations call to zend_parse_arg_long_weak(). The key line here would be https://github.com/php/php-src/blob/db894fa6aa6e98811bcc39b1331fc201e33c10ef/Zend/zend_API.c#L317: if (UNEXPECTED(zend_isnan(Z_DVAL_P(arg)))) { return 0; } Possibly zend_isnan() is broken here. ------------------------------------------------------------------------ [2017-01-17 20:21:25] ajf@php.net It doesn't use ZPP-the-function, yes, 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), which is why I linked the OP to that RFC. ------------------------------------------------------------------------ [2017-01-17 20:05:30] alex dot masterow at gmail dot com I also know about this problem. > What do you get with the following script with musl: > var_dump(chr(NAN)); string(1) "" Unicode: U+0000 HTML: &#0; ------------------------------------------------------------------------ [2017-01-17 17:49:36] cmb@php.net This has nothing to do with ZPP, because it's a userland function. What do you get with the following script with musl: <?php var_dump(chr(NAN)); ------------------------------------------------------------------------ [2017-01-17 08:53:33] zaq178miami at gmail dot com Description: ------------ It seems to be that is_nan check fails or sth like that as when passing NAN to as an int parameter it silently casted to int(0). While int(0) is valid result for explicit (int)NAN cast, according to Andrea (https://wiki.php.net/rfc/zpp_fail_on_overflow). As already discussed on SO (http://chat.stackoverflow.com/transcript/message/35136128#35136128) it might be just a musl bug, but maybe we should check what NAN do we have and maybe alter config scripts and/or php_get_nan() accordingly? Here is runnable snippet: https://3v4l.org/m7hpq Test script: --------------- <?php function test(int $test) { var_dump($test); } test(NAN); Expected result: ---------------- Fatal error: Uncaught TypeError: Argument 1 passed to test() must be of the type integer, float given, called in /in/m7hpq on line 6 and defined in /in/m7hpq:2 Stack trace: #0 /in/m7hpq(6): test(NAN) #1 {main} thrown in /in/m7hpq on line 2 Actual result: -------------- int(0) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=73954&edit=1