This is a 32bit glibc based system, so this means you didn't ask for a 64bit
time_t, then. Here's that link again that tells you how glibc handles this:
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
The Linux kernel itself is not Y2038 clean yet, AFAIK. But that's no excuse
for applications to skimp there.
We need to stick to POSIX entry points. Is there a directive we can give GCC
that tells it to map to the 64-bit versions, if available?
Quote from the document linked previously:
==========
The following is proposed:
User code defines _TIME_BITS=64 to get 64-bit time support instead
of the legacy 32-bit time.
If glibc sees _TIME_BITS=64, then it defines __USE_TIME_BITS64 to
indicate that time support is 64-bit rather than 32-bit.
==========
Configury needs to check whether it's looking at a glibc-based system
that implements that. I don't see any feature test macros discussed, so
I guess you'd check the size of some suitable datatype with and without
that define being present.
--
Achim.
(on the road :-)
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
