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:
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
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
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