Re: 64 bit time_t on riscv32

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 15/01/24 16:55, Adhemerval Zanella Netto wrote:
> 
> 
> On 15/01/24 10:40, Florian Weimer via Libc-help wrote:
>> * Antonios Salios via Libc-help:
>>
>>> According to a kernel maintainer, the __USE_TIME_BITS64 macro should be
>>> set on architectures that use 64-bit time [2], otherwise the kernel
>>> headers will not be able to pick the correct definition.
>>
>> __USE_TIME_BITS64 is an internal glibc macro.  It is not used on
>> architectures which have a 64-bit time_t by default.
>>
>> Surely the UAPI headers know which time size the architecture uses in
>> the kernel interface, and can be written arcordingly?
> 
> The use of a glibc internal definition on a kABI header is not really
> a good design.  This seems to be only user so far, so I suggest to fix
> on the kernel to not tie to a glibc internal definition. 
> 
> CCing Rich from musl that most likely would want to see this fixed. The
> Android developers might be interested.

So Arnd raised it was the agreement when it was added 2018 between glibc and 
kernel headers, and we changed the deal three years later. And not sure if 
it was on y2038 draft documentation, or on the initial patchset. Nor I
recall the discussion where it was accorded (Arnd could help me here).  

And I am not sure this is a good design, it ties glibc internal definition
to kABI meaning that glibc won't be able to refactor this code because it
might eventually break the ABI.  I think we will need at least to proper
document this somewhere to avoid future breakages.

For glibc side, I think we can always define the macro so the check would
be '__USE_TIME_BITS64 == 1' for 64 time_t support.  It would require some
internal refactoring, but it should be doable.