Linux do the similar thing: https://github.com/torvalds/linux/commit/24e4a8c3e8868874835b0f1ad6dd417341e99822#diff-97463f7cbd63070d218d2557262b21231956345f6a005557296657c1f913c788R27-R41 but it was removed in 2014.
On Wed, May 6, 2026 at 6:47 PM raiden00pl <[email protected]> wrote: > > It may be possible to combine variants 2 and 4. Have time_t always be > 64bit, add the helpers you suggested (time_add, time_diff etc.) > > This is what I meant when writing somewhere earlier in this thread. > > time_t remains 64-bit so the API is OK, any optimization hidden behind > Kconfig is done in the logic working with time_t, so no 64-bit math is > used. > This way everyone would be happy, but the question is how much of it > can be done without messing around with the code too much. > > śr., 6 maj 2026 o 12:27 <[email protected]> napisał(a): > > > > Exactly, I think only option 2 and 3 makes sense, but since you already > > > confirmed that option 2 is not worth... > > > > It may be possible to combine variants 2 and 4. Have time_t always be > > 64bit, add the helpers you suggested (time_add, time_diff etc.) > > > > Then, if chosen by a Kconfig option, the helpers could switch to > > alternate versions which would type-cast the operands to smaller size > > (say 32bit). The compiler takes care of the rest. The option obviously > > needs sufficiently visible warning about implications of selecting it > > (which implies it needs to be off by default so the user actually reads > > the warning.) > > > > Advantages: > > - time_t is 64bit > > - if some operation involving time is missed and not converted to use > > the helpers, things will still work correctly > > > > Disadvantages: > > - casting the type of the operands may suppress warnings and hide bugs > > - fairly intrusive change > > > > Unless I am missing something, this could work - not sure if something > > like this can be merged without support from 32bit world though. > > >
