[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 Nov 2022 06:34:56 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>, Jens Gustedt <jens.gustedt@...ia.fr>,
Jason Ekstrand <jason@...kstrand.net>
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,
> ```
> #ifndef CLOCK_MONOTONIC_RAW
> // 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
§7.29.1.3 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
are UTC, MONOTONIC, ACTIVE, and THREAD_ACTIVE.
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.
Ciao,
Markus
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.
