Re: [OE-core] Y2038 proposal

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2022-12-02 at 16:54 +0800, Matt Johnston wrote:
> Your email prompted me to check my own software (Dropbear) and it showed a
> few y2038 issues to fix. Those bugs wouldn't be noticed from a quick test -
> it "only" prevented auth and idle timeouts from occurring.
> 
> gcc and clang are able to flag truncated conversions for 64-bit time_t with 
> -Wconversion, but that's very noisy. Comparing that against a 32-bit time_t
> build, however, gives a pretty clean list of code that needs attention.
> 
> As an experiment I've built OpenBMC with and without 64-bit time_t,
> https://github.com/mkj/yocto-y2038 has the results and a description. There
> are a mix of false positives (particularly tv_usec/tv_nsec), but also some
> real-looking things. As an example, busybox using a uint32_t to copy a dhcpd
> lease expiry.
> 
> I'm not sure the best way to use these logs - they need manual review.
> Expanding the list of packages should be easy, but there will be more that
> need manual intervention to get rid of -Werror.

That is really interesting data as it confirmed there are real world
issues which changing the compiler flags is going to break. Thanks for
sharing.

What you describe is relatively easy for a maintainer to do as a one
off check but not really something we can do at scale for all the
software we build. It worries me :/. I guess the one upside is that
whilst it did break some functionality, it didn't actually crash the
runtime if I understand what happened correctly.

I'm not sure this should stop our plan to switch the flags but it is
certainly something to think about and be aware of.

Cheers,

Richard