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.