[php-src] Issue #19210: [zend_]hrtime() returns constant value if unavailable or on error

From: Date: Tue, 22 Jul 2025 10:17:26 +0000
Subject: [php-src] Issue #19210: [zend_]hrtime() returns constant value if unavailable or on error
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-250471@lists.php.net to get a copy of this message
Issue: https://github.com/php/php-src/issues/19210 Author: marc-mabe ### Description Sorry, for not following the bug template as this is a theoretical bug I can't reproduce together with a structural issue. zend_hrtime() returns a constant value of 0 in case it's unavailable or in case of error. The problem is that the availability isn't checked (ftp and zend_gc) and additionally the error condition could be a valid value. -> As a result the time measurements might be buggy. Similar situation for hrtime(). In case of error it will report a zero value which is a valid result. In case of unavailability it will return false but normally if a functionality is unavailable in PHP it drops the function instead of returning a constant falsy value. I haven't found an RFC for this feature, just a small [ML discussion](https://externals.io/message/97502) and the [PR](https://github.com/php/php-src/pull/2976). I would like to use zend_hrtime() for time measurements where current gettimeofday() is used (like in [openssl](https://github.com/php/php-src/blob/a7fef37657c407201b520d4960c720b9db135573/ext/openssl/xp_ssl.c#L1834-L1857) and others) but currently this could silently fail and break the logic. As it's already in use without checking availability/error I wonder if PHP actually supports systems where this is not available and if an error can actually happen. Either the constant return should be removed -> make it fail to compile if unavailable and fail hard on error or the function should not be made unavailable and make it somehow possible to safely check the error condition. WDYT? ### PHP Version ```plain PHP >= 7.3.0 ``` ### Operating System _No response_

« previous php.bugs (#250471) next »