Bug #73954 [Asn]: 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: 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: (Sure enough, it's mine. I moved it from ext/standard, but it was already in a different m4 file in Zend. Oops.) Previous Comments: ------------------------------------------------------------------------ [2017-02-05 00:10:42] ajf@php.net I'm not sure if that PR actually fixes the issue, but I'll test it. Side-note: we currently define zend_isnan() twice, in both Zend.m4 and configure.m4. I don't know why, that might be my fault. ------------------------------------------------------------------------ [2017-02-04 23:56:29] nikic@php.net Note that there is a PR up to fix this issue: https://github.com/php/php-src/pull/2356 ------------------------------------------------------------------------ [2017-02-04 23:47:21] ajf@php.net Okay, I got an Alpine install up and running in a VM and I can reproduce this for php-src master: localhost:~/php-src# uname -a; sapi/cli/php -v; sapi/cli/php -r 'function foo(in t $x) {} var_dump(foo(NAN));' Linux localhost 4.4.45-0-virtgrsec #1-Alpine SMP Thu Jan 26 14:32:43 GMT 2017 x86_64 Linux PHP 7.2.0-dev (cli) (built: Feb 4 2017 23:35:47) ( NTS DEBUG ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.2.0-dev, Copyright (c) 1998-2017 Zend Technologies NULL Whereas on macOS: Andreas-MacBook-Air:php-src ajf$ uname -a; sapi/cli/php -v; sapi/cli/php -r 'function foo(int $x) {} var_dump(foo(NAN));' Darwin Andreas-MacBook-Air.local 16.4.0 Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64 PHP 7.2.0-dev (cli) (built: Jan 31 2017 21:23:57) ( NTS DEBUG ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.2.0-dev, Copyright (c) 1998-2017 Zend Technologies with Zend OPcache v7.2.0-dev, Copyright (c) 1999-2017, by Zend Technologies Fatal error: Uncaught TypeError: Argument 1 passed to foo() must be of the type integer, float given, called in Command line code on line 1 and defined in Command line code:1 Stack trace: #0 Command line code(1): foo(NAN) #1 {main} thrown in Command line code on line 1 ------------------------------------------------------------------------ [2017-01-19 10:16:42] cmb@php.net Thanks for the explanation, Andrea. So this is solely a musl issue. ------------------------------------------------------------------------ [2017-01-19 00:22:29] ajf@php.net > See <https://3v4l.org/PHBQK>. Why does Z_PARAM_LONG > accept NAN, > but a userland int type declaration does not? chr() uses ZEND_PARSE_PARAMS_QUIET to suppress errors in parameter parsing, so it does not display the normal behaviour. It ignoring NAN is expected. Additionally, chr() usually doesn't actually get called, because it is a special-cased function which zend_compile.c replaces with an opcode. ------------------------------------------------------------------------ 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