Skip to content

[zend_]hrtime() returns constant value if unavailable or on error #19210

Closed

Description

@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 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.

WDYT?

PHP Version

PHP >= 7.3.0

Operating System

No response

Activity

  1. iluuu1994 commented on Jul 22, 2025

    @iluuu1994
    Member

    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)

  2. ndossche commented on Jul 22, 2025

    @ndossche
    Member

    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.

  3. iluuu1994 commented on Jul 22, 2025

    @iluuu1994
    Member

    What platform doesn't support such timers?

    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.

  4. TimWolla commented on Jul 23, 2025

    @TimWolla
    Member

    Somewhat relatedly, I was considering making a working CSPRNG mandatory for a while.

  5. ndossche commented on Jul 23, 2025

    @ndossche
    Member

    Worth noting that the implementation that uses clock_gettime can't actually fail and return 0 unless CLOCK_MONOTONIC is unsupported.

  6. marc-mabe commented on Oct 9, 2025

    @marc-mabe
    ContributorAuthor

    Closed now with #19218 , #19219 and #19221 being merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions