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.
