You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[zend_]hrtime() returns constant value if unavailable or on error #19210
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 and the PR.
I would like to use zend_hrtime() for time measurements where current gettimeofday() is used (like in openssl 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.
The uses in Zend/zend_gc.c are purely informative, so they shouldn't be problematic (other than being wrong). ext/ftp/ftp.c might be problematic, in that it doesn't correctly respect the timeout. With repeated interrupts, this can keep looping. @nielsdos (as author of #17327)
What platform doesn't support such timers?
While we could use gettimeofday, it is not correct as it's not a monotonic clock. So one "workaround" is to just always break on interruptions on unsupported platforms, this would "restore" the old buggy behaviour but may be "good enough" for such platforms.
Also worth noting that on such platforms, the hrtime() PHP function causes a ZPP/arginfo violation.
Activity
iluuu1994 commentedon Jul 22, 2025
The uses in Zend/zend_gc.c are purely informative, so they shouldn't be problematic (other than being wrong). ext/ftp/ftp.c might be problematic, in that it doesn't correctly respect the timeout. With repeated interrupts, this can keep looping. @nielsdos (as author of #17327)
ndossche commentedon Jul 22, 2025
What platform doesn't support such timers?
While we could use gettimeofday, it is not correct as it's not a monotonic clock. So one "workaround" is to just always break on interruptions on unsupported platforms, this would "restore" the old buggy behaviour but may be "good enough" for such platforms.
Also worth noting that on such platforms, the hrtime() PHP function causes a ZPP/arginfo violation.
iluuu1994 commentedon Jul 22, 2025
That part is questionable. I'm not sure if there are any in practice that wouldn't also have significant problems elsewhere.
So, not sure if it makes sense hunting down a theoretical problem. I'll leave that judgement up to you.
TimWolla commentedon Jul 23, 2025
Somewhat relatedly, I was considering making a working CSPRNG mandatory for a while.
Fix arginfo/zpp violation if zend_hrtime is not available
Handle broken hrtime in ftp
ndossche commentedon Jul 23, 2025
Worth noting that the implementation that uses
clock_gettimecan't actually fail and return 0 unlessCLOCK_MONOTONICis unsupported.Fix arginfo/zpp violation if zend_hrtime is not available
Handle broken hrtime in ftp
marc-mabe commentedon Oct 9, 2025
Closed now with #19218 , #19219 and #19221 being merged.