Thanks for reporting!

Indeed, that cast is wrong, but most important seems that we should check that timeout is in the permissible range before even calling the function, and throw a ValueError otherwise (not sure if throwing is okay for stable branches, though).

A comment on the patch.

When the function returns -1, it would be good to always set some Curl error. Otherwise the caller cannot know to which Curl function call the error fetched with curl_multi_errno refers.

Specifically, we can use SAVE_CURLM_ERROR(mh, CURLM_BAD_FUNCTION_ARGUMENT) because this error code is also set in Curl when the timeout is negative: https://github.com/curl/curl/blob/df15d9ff26170125cbaa4d9283f733a2bb35fa20/lib/multi.c#L1288

As a code simplification, we could also assert timeout >= 0.0 because negative values are disallowed anyway. (Curl should better use the unsigned int type here.)

sure, fair point for setting curl error.

we have issue with <b>Warning</b>: curl_multi_select(): timeout must be between 0 and 2147484 in <b>/apps/symfony-app/vendor/symfony/http-client/Response/CurlResponse.php</b> on line <b>342</b><br /> in response body.

but if display_errors = Off, then we expect this message in logs, nope in response body.

i don't know if it's depended, but in php-8.4.0RC2 is used zend_argument_value_error() instead of php_error_docref().

It s documented on the UPGRADING notes.

@novotnicek Maybe you (or somebody) can explain what the main reason of error curl_multi_select(): timeout must be between 0 and 2147484 ? I understand that timeout has negative value but why ? And how can I fix it ? My PHP version 8.2.24 and recently I've upgraded docker base image php:8.2-fpm-alpine17 up to php:8.2-fpm-alpine20 and now I have this warning.

@thezagday You problem is not alpine17 or alpine20, but PHP patch version (third number in semver). I don't have problem with this warning. I see like problem, this warning ended in response body instead of log files, when my setting is display_errors = Off.