|
Message-ID: <20221120053456.GA2497@voyager> 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.