On Tue, Nov 5, 2024 at 9:46 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > > On Tue, Nov 5, 2024 at 3:07 PM Tomek CEDRO <to...@cedro.info> wrote: > > > > Yet another (probably silly) idea: how about giving choice if 32 > > and/or 64 bit time is signed or unsigned in the kconfig and the > > summary warning at the end of build? This way developers could select > > what they want to use? > > This could give developers complete control, if they want something > different than what we decide. But, which would be default? On 32-bit > and 64-bit archs, I suggest to use the 64 bit signed type as default. > On 8-bit and 16-bit archs, I suggest to use 32-bit unsigned as > default. Developers who want something different can choose whichever > combo they want. > > The ---help--- text for 32-bit signed should contain a WARNING: Your > product will have a year 2038 problem if you choose this option! > > Also, I think we had a Kconfig in the past to choose the epoch. Is > this still possible? Perhaps developers who never expect to deal with > dates before the product release (e.g., 2024) could set the epoch to > 01-01-2024 and use a 32-bit type? Various functions in the OS might > have to be updated to accommodate such a Kconfig.
Okay so summing up all the problems and solutions this may be common denominator: 1. Kconfig selectable `uint32_t time_t` as default on <= 32-bit targets, can be changed to `int32_t time_t`. 2. Kconfig selectable `int64_t time_t` as default on 64-bit targets, can be changed to `uint64_t time_t`. 3. Casting to (int) on time comparison + patching code / upstreams. There is an inconsistency, but there is a choice. Nathan you mentioned the 8-bit and 16-bit platforms to use 32-bit unsigned. That would imply "virtual" type not natively supported by platform. Do you know what is the penalty for using such types? Is it safe? Does it work on all compilers? Is it slow? if no, then maybe we could also use int64_t on 32-bit platforms? :-P -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
