Too big float to int cast results nonsense

[mvorisek]

Description

repro: https://3v4l.org/0FJkO

I discovered this in library where big timeout was converted to milliseconds like $timeoutFloat * 1000 and later casted into integer which resulted very dangerous 0 without any warning.

I would expect some warning like https://3v4l.org/4C3ru when too big float is impossible to be casted meaningfully into int.

[TimWolla]

I would expect some warning like https://3v4l.org/4C3ru when too big float is impossible to be casted meaningfully into int.

That's an implicit conversion. An explicit cast does not warn: https://3v4l.org/F9Ir7.

Similarly implicitly converting this large float to an int will already throw an error: https://3v4l.org/6NnZ6

In any case, given that this affects the core language functionality, this requires an RFC.

[mvorisek]

As the first step of this/my feature request, I would expect PHP_INT_MAX for float larger than the max. integer value.

The warning is second priority.

[iluuu1994]

Casting huge ints to floats also loses precision. Deciding what should warn and what shouldn't is not trivial. I also think this should be discussed first.

[mvorisek]

In this issue I want to focus solely on https://3v4l.org/4gVYb behaviour which is very dangerous and not much expected from user POV. I would expect the resulting integer to be capped to PHP_INT_MAX/PHP_INT_MIN with the correct sign.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.

[mvorisek]

I belive this is manageable, where in the code the float to int is casted? I belive we should and can cap it to int max/min.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.

[mvorisek]

Can someone please point me to the php-src file/line where the cast from float to int is done?

[nielsdos]

Can someone please point me to the php-src file/line where the cast from float to int is done?

php-src/Zend/zend_operators.h

Lines 130 to 140 in 4f0554f

	/* Used to convert a string float to integer during an (int) cast */
	static zend_always_inline zend_long zend_dval_to_lval_cap(double d)
	{
	if (UNEXPECTED(!zend_finite(d)) || UNEXPECTED(zend_isnan(d))) {
	return 0;
	} else if (!ZEND_DOUBLE_FITS_LONG(d)) {
	return (d > 0 ? ZEND_LONG_MAX : ZEND_LONG_MIN);
	}
	return (zend_long)d;
	}
	/* }}} */

[mvorisek]

So the case should be handled, but it isn't. Any idea why?

Here is simpler repro: https://3v4l.org/JauAu

-actual
+expected
 9.2233720368548E+21
 9223372036854775807
-0
+9223372036854775807

[nielsdos]

Ah because I pointed to the wrong location.
The location I pointed at is for string floats, not floats.
zend_dval_to_lval is used for floats, which will call zend_dval_to_lval_slow which doesn't cap.

[mvorisek]

Initially I opened this as a feature to get a warning emit. Let this issue be not about a warning, but about the result.

Can this issue be please changed to a bug /wo RFC?

I belive it is a bug because of these reasons:

1. the result is not always 0 - repro https://3v4l.org/lYgYh
2. the result is inconsistent on x86 vs. x64 (x86 can be checked by editing the 3v4l.org testcase in live-local-preview)

[nielsdos]

It needs an RFC regardless because it changes behaviour that so long standing that people may (unknowingly) rely on it. I'm also quite certain that people will argue a lot about the desired behaviour.
If an RFC comes from this, it should also make the string float casting behaviour consistent with the normal float casting behaviour. I was surprised this is different.