[PATCH v2] time: Add TIME_MONOTONIC, TIME_ACTIVE, and TIME_THREAD_ACTIVE

[Adhemerval Zanella Netto]

On 25/11/25 05:27, Paul Eggert wrote:
> On 2025-11-24 10:29, Adhemerval Zanella wrote:
>> +* The ISO C23 optimal time base TIME_MONOTONIC, TIME_ACTIVE, and
>> +  TIME_THREAD_ACTIVE have been added.
> 
> I assume you meant "optional" not "optimal"?

Oops, yes.

> 
> Also, shouldn't this new feature be documented in the manual?

Indeed, I will extend for the new timebases.

> 
>> +  clockid_t clockid = clock_from_timebase (base);
>> +  if (clockid < 0)
>> +    return 0;
>> +  return __clock_gettime64 (clockid, ts) == 0 ? base : 0;
> 
> Wouldn't it be a bit faster, and even a bit future-proofier, to do this?
> 
>    return __clock_gettime64 (clockid - 1, ts) == 0 ? base : 0;
> 
> Speed can matter in clock routines....

I haven't done it because I did not want to tie the POSIX clocks definition
to the C one. But it seems from Florian remarks and a recent topic on
libc-coord [1] that it would be useful to add a GNU extension to convert
the clocks.

But at least for glibc the 'clockid - 1' works on all supported platforms,
I will change it.

[1] https://www.openwall.com/lists/libc-coord/2023/04/25/1 

> 
> 
>>  int
>>  __timespec_getres (struct timespec *ts, int base)
>>  {
>> -  int ret;
>>    struct __timespec64 tp64;
>>  
>> -  ret = __timespec_getres64 (&tp64, base);
>> +  if (__timespec_getres64 (&tp64, base) != 0 && ts != NULL)
>> +    {
>> +      *ts = valid_timespec64_to_timespec (tp64);
>> +      return base;
>> +    }
>>  
>> -  if (ret == TIME_UTC && ts != NULL)
>> -    *ts = valid_timespec64_to_timespec (tp64);
>> -
>> -  return ret;
>> +  return 0;
> 
> Why change from the old way of doing "return ret;"? In other words, why not do something like this?
> 
>   struct __timespec64 tp64;
>   int ret = __timespec_getres64 (&tp64, base);
>   if (ret != 0 && ts != NULL)
>     *ts = valid_timespec64_to_timespec (tp64);
>   return ret;
> 
> This way, the compiler doesn't need to save and restore BASE so the code can be a tiny bit smaller and faster.

Not reason in particular, the functions already requires multiple function
calls so I think micro-optimizing here does not matter much.  I will use
your suggestion.