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));

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

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.

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.

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.

> 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().

It seems to me that the NaN handling is broken (not only with
musl). Andrea, could you please take a closer look at this?

I can look into it, but it works for me. So, what particular OS, compiler and version are you dealing with?

> 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

> 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/>

> 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.

Thanks for the explanation, Andrea. So this is solely a musl
issue.

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

Note that there is a PR up to fix this issue: https://github.com/php/php-src/pull/2356

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.

(Sure enough, it's mine. I moved it from ext/standard, but it was already in a different m4 file in Zend. Oops.)

…no, wait, I just can't read source code properly without syntax highlighting. Ignore me, sorry.

Thank you for taking care!