On Thu, Nov 7, 2024 at 7:01 PM Gregory Nutt <spudan...@gmail.com> wrote: > On 11/7/2024 10:59 AM, Tomek CEDRO wrote: > > Does adding kconfig's configurable time_t with uint32_t default > > (as-is) with option to change int32_t and int64_t sounds good? Should > > we use manual selection only or auto-detection (i.e. int64_t on 64-bit > > archs)? :-) > > ==== /Initial Response /==== > > Not really. The POSIX specification for time_t is still under work. > Just changing the type to int64_t is one likely result amongst others. > I would not invest the effort in the timing calculations for an > arbitrary non-standard solution. I would wait for the specification to > be released and not waste effort guessing what the standard will be. > > "In a future version of this volume of POSIX.1-2017, *time_t* is > likely to be required to be capable of representing times far in the > future. Whether this will be mandated as a 64-bit type or a > requirement that a specific date in the future be representable (for > example, 10000 AD) is not yet determined. Systems purchased after > the approval of this volume of POSIX.1-2017 should be evaluated to > determine whether their lifetime will extend past 2038." > https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html > > If you are a gambling man and don't mind the risk of re-working time_t > related logic, then I would bet on the type being int64_t as you are > advocating. What will be the units of time? Still 1 sec? Probably > not. Perhaps time_t will become a structure? We don't really know. > int64_t is not a bad bet but not substantiated by specification yet either. > > > This provides backward compatibility, easy configuration versatility / > > fine tuning, and we may change the default when new POSIX standard is > > ratified? :-) > > Which might be a big job and might make all of that non-standard, > unspecified implementation throw-away code.If someone wants to go > through that effort and verify/fix all of the timing calculation > functions as needed to support int54_t time_t, I would not oppose that. > > ==== /LATER /==== > > */Never mind/*. POSIX 2024 has just been released and time_t is now > required to be 64-bits. Lots and lots of other changes as well. > > * https://sortix.org/blog/posix-2024/ > > The 2038 32-bit |time_t| apocalypse has been canceled to contain > SCP-8601 <https://scp-wiki.wikidot.com/scp-8601>. > > * > https://www.reddit.com/r/C_Programming/comments/1e2ac63/new_features_for_c_in_posix_2024/?rdt=50686 > > |time_t| is now required to be 64-bit. Farewell year 2038 problem. > > I have seen on these POSIX summaries and would really like to see the > language of the actual spec. At any rate, will a solid basis in > specifications. I now agree with you. time_t must 64 bits on all > platforms and with all tools.
Yes Byron referenced POSIX 2024 a bit earlier this is exactly why I proposed to set int64_t time_t as default already :-P :-P Still it will be possible to set _by_hand_ other values (i.e. int32_t or uint32_t) via kconfig when necessary for older / smaller platforms. I like the idea of auto-detection but I am afraid this will lead to inconsistencies and confusion so nothing is done behind the back and if developer wants to change time_t type it should be manual conscious choice :-) I must underline here how much I really love NuttX - no rush, no enforced changes, in depth analysis and constructive approach by the small but mature developers community - what a wonderful environment to learn and grow, thank you :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
