This is related to my previous question where I asked if std::chrono::steady_clock::now
should be noexcept
. Now that I know that it should I wonder how does this function report errors? For example, a common implementation of this function on Linux uses
clock_gettime which can return an error.
All of the errors that could be reported by the Linux clock_gettime
facility are not possible in a debugged implementation of std::chrono::steady_clock::now()
.
The errors are:
int clock_gettime(clockid_t clk_id, struct timespec *tp);
EFAULT
tp points outside the accessible address space.
There is no user-supplied tp
to get wrong in std::chrono::steady_clock::now()
. If std::chrono::steady_clock::now()
passes the wrong tp
to clock_gettime
, it is just a bug in steady_clock
that is easily fixed.
EINVAL
The clk_id specified is not supported on this system.
There is no user-supplied clk_id
to get wrong in std::chrono::steady_clock::now()
. If std::chrono::steady_clock::now()
passes the wrong clk_id
to clock_gettime
, it is just a bug in steady_clock
that must be fixed.
Note that an implementation of steady_clock
isn't guaranteed to be portable, and may have to be ported to any given platform and be tested for correctness. It might turn out that steady_clock
can not be implemented in terms of clock_gettime
on some platforms.
EPERM
clock_settime() does not have permission to set the clock indicated.
Not applicable to steady_clock
as there is no API to set the time.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With