This still does not solve issues on 8 and 16 bit platforms (i.e. non-atomic access, overflows). The problem may be just less visible / painful. I think we need "default" and "portable" implementation that would both provide POSIX compliant time functionality (int64_t)?
-- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Mon, May 4, 2026 at 2:19 PM Michal Lenc <[email protected]> wrote: > > > I like the idea of 64-bit time_t being the default with a way to reduce it > > when appropriate for a particular use case. The Kconfig "---help---" text > > could warn that less than 64-bit is non-POSIX and the consequences of using > > less than 64 bits, and let the developer decide. By default we'll be > > 64-bits and complying with POSIX on this issue. > > I think this is the ideal "common ground". Let's make 64 bit time > default and replace the CONFIG_SYSTEM_TIME64 > option with CONFIG_SYSTEM_TIME32 one that would still use 32 bit time > for use cases where this is required. This way we will keep POSIX > compatibility and also leave open door for older platforms with less > flash/RAM. > > Michal > > On 5/4/26 14:03, Nathan Hartman wrote: > > One of the nicest things about NuttX is that you can use it with any > > microcontroller. That's the biggest selling point for me: instead of using > > a different set of vendor libraries for each microcontroller, you can > > standardize on NuttX and your code becomes portable across microcontrollers > > regardless of vendor. > > > > If we start leaving microcontrollers behind, first it will be 8-bit > > microcontrollers, then likely it will be 16-bit, eventually we'll be a > > large and heavy OS that only works on powerful, expensive chips. > > > > I like the idea of 64-bit time_t being the default with a way to reduce it > > when appropriate for a particular use case. The Kconfig "---help---" text > > could warn that less than 64-bit is non-POSIX and the consequences of using > > less than 64 bits, and let the developer decide. By default we'll be > > 64-bits and complying with POSIX on this issue. > > > > My 2¢... > > > > Nathan > > > > On Mon, May 4, 2026 at 7:43 AM Alan C. Assis <[email protected]> wrote: > > > >> I wasn't aware that libfaketime was facing an issue with the time_t moving > >> to 64-bit ? > >> > >> https://github.com/wolfcw/libfaketime/issues/418 > >> > >> I think in our case we don't have any issue (I hope), other than the code > >> increasing and a worse performance on 8/16/32-bit MCUs. > >> > >> BR, > >> > >> Alan > >> > >> On Sun, May 3, 2026 at 4:22 PM Gregory Nutt <[email protected]> wrote: > >> > >>> There are some compilers that do not support uin64_t natively. For > >> those, > >>> library support would be needed. > >>> > >>> If an implementation requires multiple accesses to read/write uint64, > >> then > >>> the accesses would be non-atomic. At a bare minimum, the locked section > >>> would be required (which would not prevent concurrent accesses from > >>> interrupt handlers). > >>> > >>> I support the POSIX first prioritization. I removed a lot of support > >>> needed by some of these architectures in the past for similar reasons. > >>> That broke certain compilers and a lot of implementations (which are > >> still > >>> broken). We should probably do the same, but with full awareness of > >>> functionality well will use or things that are very broken. > >>> > >>> I have suggested removing support for the 8 bit architectures and for > >>> compilers like the ZDS and SDCC compilers. Carrying architectures with > >>> this level of breakage is misleading. > >>> > >>> ________________________________ > >>> From: [email protected] <[email protected]> > >>> Sent: Sunday, May 3, 2026 9:42 AM > >>> To: [email protected] <[email protected]> > >>> Subject: Re: [DISCUSS] Removal of CONFIG_SYSTEM_TIME64 and make time_t > >>> 64-bit by default > >>> > >>> Hello, > >>> > >>> I tried for AVR128DA28 - tools/configure.sh -l breadxavr:nsh > >>> > >>> Default setting (CONFIG_SYSTEM_TIME64 not set): > >>> > >>> Register: nsh > >>> Register: sh > >>> LD: nuttx > >>> Memory region Used Size Region Size %age Used > >>> flash: 50457 B 128 KB 38.50% > >>> sram: 636 B 16 KB 3.88% > >>> eeprom: 0 B 512 B 0.00% > >>> rodata: 592 B 4 KB 14.45% > >>> CP: nuttx.hex > >>> CP: nuttx.asm > >>> > >>> With CONFIG_SYSTEM_TIME64 set: > >>> > >>> Register: nsh > >>> Register: sh > >>> LD: nuttx > >>> Memory region Used Size Region Size %age Used > >>> flash: 52307 B 128 KB 39.91% > >>> sram: 668 B 16 KB 4.08% > >>> eeprom: 0 B 512 B 0.00% > >>> rodata: 592 B 4 KB 14.45% > >>> CP: nuttx.hex > >>> CP: nuttx.asm > >>> > >>> 2kB seems quite noticeable for a chip with 128kB flash. Runtime costs > >>> are somewhat hard to assess, the time_t type is used in internal > >>> timekeeping but the code was developed with tickless mode of operation > >>> in mind so the timekeeping functions should not run that often unless > >>> the system gets busy with processing lots of timed events. > >>> > >>> As for the benefits - the real question is how many devices (designed > >>> with a chip like this one) need to know real time and therefore handle > >>> year 2038. (None of my use cases need that.) > >>> > >>> So for small systems, having the option to configure NuttX so time_t is > >>> 32 bit wide would certainly be beneficial. Making the SYSTEM_TIME64 > >>> option default to DEFAULT_SMALL would be nice but it's not POSIX-correct > >>> so I don't think that's gonna fly. > >>> >
