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: nikic@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: Note that there is a PR up to fix this issue: https://github.com/php/php-src/pull/2356 Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2017-01-18 23:00:21] cmb@php.net > 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/> ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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