Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 25 Apr 2023 11:14:36 +0100
From: Jonathan Wakely <>
Subject: Relation between C timespec_get time bases and POSIX clockid_t values.

C11 added timespec_get and the constant TIME_UTC. POSIX extends this by
requiring TIME_UTC to use the same clock as CLOCK_REALTIME. However,
TIME_UTC is required to be non-zero, and CLOCK_REALTIME is zero on existing

C23 adds TIME_MONOTONIC, and (optionally supported) TIME_ACTIVE and
TIME_THREAD_ACTIVE. Presumably a future version of POSIX will say those use

It would be helpful if POSIX guaranteed that every C time base can be
converted to a POSIX clockid_t by adding the constant value (TIME_UTC -
(int)CLOCK_REALTIME). This would allow programs using both timespec_get and
clock_gettime to use a single value for a given clock, and easily convert
to the other domain. For example, a program using timespec_get in one
module (which might be written in portable ISO C) might want to pass a
clock to pthread_cond_timedwait in another module (written in POSIX C).
This could also be relevant to a proposed C++ extension that would expose
the underlying clock used by C++ clocks such as std::chrono::system_clock
and std::chrono::steady_clock (see for details).

In the absence of a POSIX guarantee, it would be helpful if C libraries
guaranteed how to convert a C time base to a POSIX clockid_t ASAP.

Is that practical to guarantee today? Are there any implementations that
already support C bases other than TIME_UTC, where the mapping from
TIME_foo to CLOCK_foo is not a simple addition?

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.