A simple alternative would be to configure a "bytes per time_t" value and if that is not not 8, then provide a library function that implements uint64_t with multiple byte accesses and provides atomic operation. This would not be so difficult and would eliminate any significant size increase but would trash performance on low-end microcontrollers.
________________________________ From: Alan C. Assis <[email protected]> Sent: Sunday, May 3, 2026 10:46 AM To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Removal of CONFIG_SYSTEM_TIME64 and make time_t 64-bit by default Yes, that was my point, but "I was outvoted". I think making it default will avoid this issue in 99.9% of all devices (because only people trying to run NuttX on small devices will try to disable it). And if POSIX compatibility is the problem, we could print a WARNING at the end of compilation saying: your firmware is not POSIX compatible because you disabled CONFIG_SYSTEM_TIME64. I think 2KB+ means we no longer will be able to support boards with less than 32KB Flash. BR, Alan On Sun, May 3, 2026 at 1:43 PM <[email protected]> wrote: > 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. >
