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