> 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. >
