https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116586
Bug ID: 116586
Summary: All uses of absolute timeouts should correctly handle
negative times
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
POSIX doesn't require any APIs to handle times before the epoch, so any time we
have a chrono::time_point that gets converted to a timespec and passed to
something like pthread_cond_timedwait or sem_timedwait we should check for
negative time points.
It seems reasonable to assume the system clock is not set to a time before the
epoch, so we can just treat any negative time_point as being in the past and so
timeout immediately.
For timeouts that use the steady_clock I think we can also assume the clock's
unspecified epoch is in the past, i.e. that steady_clock::now() is always a
non-negative time point. That's true for linux. POSIX says the clock gives you
the time since some unspecified point in the past, which I hope means "since an
unspecified epoch, which is guaranteed to be in the past".
We have a patch for std::future timeouts:
https://patchwork.sourceware.org/project/gcc/patch/20240724131238.271095-1-william.t...@sifive.com/
condition_variable and timed mutexes and __platform_semaphore need a fix.
