Otherwise there would be 2038 issue
Thanks for pointing this out and sorry for the delay in response here. We have recently updated this type to
__INTPTR_TYPE__ which should make
time_t to be 64-bits wide on 64-bit platforms: llvm-project/time_t.h at main · llvm/llvm-project · GitHub
AFAIU, this is the convention used by other popular libcs. But, if you feel we ought to make it 64-bit even for 32-bit platforms, we should probably discuss more about how such a definition would affect other platform specific pieces (for example, the Linux syscalls).
FWIW, musl switched to universally using a 64-bit time_t, back in 2019. So, it’s definitely possible to do it on 32-bit Linux ports.
That doesn’t fix anything other than 32-bit Windows, and makes it worse in other ways. On 64-bit non-Windows platforms long is already 64-bit, and 32-bit platforms, even non-Windows, have a 32-bit long and intptr_t so this hasn’t changed anything there. Then you have architectures like CHERI where intptr_t is very wrong, because they make a distinction between pointers and integers, with intptr_t being treated more like a pointer, and time_t is very much a plain integer and has no pointer-ness to it.
If you want a 64-bit integer, use int64_t. If you want a machine word, use something like size_t, which is still not quite right but close enough in practice. But intptr_t is never the right type for something that’s exclusively used as a plain integer.
(And this goes for most, if not all, of the other
__[U]INTPTR_TYPE__ uses in the same commit; I haven’t surveyed them other than to see that dev_t and ino_t are following the same misguided approach)
That’s doesn’t fixes the year 2038 issue for 32bit system, I think be int64_t should be better and consistence with musl
If there are architectures/platforms where
__[U]INTPTR_TYPE__ is not desirable, we will be happy to either change to a more acceptable type, or add specializations/exceptions.