[Buildroot] [PATCH] Config.in: introduce BR2_TIME_BITS_64 option for Y2038 compatibility

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni at bootlin.com> writes:

 > Y2038 is now almost only 15 years away, and embedded systems built
 > today are potentially going to still be operational in 15 years, and
 > even though they are supposed to receive updates by then, we all know
 > how things go, and potentially some of these embedded systems will not
 > receive any update.

Thanks for picking this up! This has been on my todo list for a while as well!.


 > In 2038, the signed 32-bit representation of time_t used on 32-bit
 > architectures will overflow, causing all time-related functions to go
 > back in time in a surprising way.

 > The Linux kernel has already been modified to support a 64-bit
 > representation of time_t on 32-bit architectures, but from a C library
 > perspective, the situation varies:

 >  - glibc uses this 64-bit time_t representation on 32-bit systems
 >    since glibc 2.34, but only if -D_TIME_BITS=64 is
 >    specified. Therefore, this commit adds an option to add this flag
 >    globally to the build, when glibc is the C library and the
 >    architecture is not 64-bit.

 >  - musl uses unconditionally a 64-bit time_t representation on 32-bit
 >    systems since musl 1.2.0. So there is nothing to do here since
 >    Buildroot has been using a musl >= 1.2.0, used since Buildroot
 >    2020.05. No Buildroot option is needed here.

 >  - uClibc-ng does not support a 64-bit time_t representation on 32-bit
 >    systems, so systems using uClibc-ng will not be Y2038 compliant, at
 >    least for now. No Buildroot option is needed here.

 > It should be noted that being Y2038-compliant will only work if all
 > application/library code is correct. For example if an
 > application/library stores a timestamp in an "int" instead of using
 > the proper time_t type, then the mechanisms described above will not
 > fix this, and the application/library will continue to be broken in
 > terms of Y2038 support.

 > Possible discussions points about this patch:

 >  - Should we have an option at all, or should we unconditionally pass
 >    -D_TIME_BITS=64, like we have been doing for _FILE_OFFSET_BITS=64
 >    for quite some time. The reasoning for having an option is that
 >    the mechanism is itself opt-in in glibc, and generally relatively
 >    new, so it seemed logical for now to make it optional as well in
 >    Buildroot.

I was hoping we could just do it unconditionally, given that musl does
it already.

Failing that, I would think we could at least make it default y.


 >  - Should we show something (a Config.in comment?) in the musl and
 >    uClibc-ng case to let the user know that the code is Y2038
 >    compliant (musl) or not Y2038 compliant (uClibc-ng). Or should this
 >    discussion be part of the Buildroot documentation?

Having a notice about this in the documentation certainly cannot
harm. I'm not sure it makes sense to have it in Config.in.

-- 
Bye, Peter Korsgaard