Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 Nov 2022 06:34:56 +0100
From: Markus Wichmann <>
Cc: Rich Felker <>, Jens Gustedt <>,
	Jason Ekstrand <>
Subject: Re: C23 implications for C libraries

On Sun, Nov 20, 2022 at 12:25:21PM +0800, 罗勇刚(Yonggang Luo) wrote:
> That's the issue, when you access `CLOCK_MONOTONIC_RAW`, it's have to be
> defined, suppose we have
> standardized TIME_MONOTONIC_RAW, then we have no need get the time with,
> ```
>  // The code
> #endif
> ```
> but with
> ```
> if (timespec_get(ts, TIME_MONOTONIC_RAW) != 0) {
> }
> ```

But the standard defines these additional clocks as optional, too,
right? I'm looking at a C23 draft from Sept. 3rd, 2022, and it says in
§ sentence 1:

"The definition macros for time bases other than TIME_UTC are optional."

Meaning even a fully conforming implementation does not have to define
these. Never mind the fact that TIME_MONOTONIC_RAW is not mentioned in
there, ever. The implementation is allowed to add further names
beginning with TIME_ to the header, but the only time bases mentioned

The Vulkan people are also likely to not want to throw away
compatibility with existing libcs that are not yet C23 capable,
especially for something so minor as a timestamp. The current code works
only on Linux, but it works as long as libc is young enough to define
the time base. The C23 time base you are proposing can only be supported
if the Linux time base is also supported, so the set of libcs supporting
this extension is necessarily a subset of the ones supporting the
existing code. Narrowing the set of supported libcs does not seem
prudent to me.


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.