The standard says that time_t "is an integer type of at least 64 bits." So for small systems, maybe we need to think from the other side - how to optimize memory usage for systems that don't care about time, but without touching the definition of time_t. I understand that there are applications that don't care about absolute time, or even - don't care about time at all. I have built several such applications myself.
Perhaps the solution is to disable time handling at all (not sure if possible) or optimize the time calculations. I thought about it once, but I had to move on to other topics before I came up with something useful :) pon., 4 maj 2026 o 17:31 Matteo Golin <[email protected]> napisał(a): > What I will say as a bit of an aside is that a few things have mentioned > here in regards to optimizations that can be made to fit in a smaller > footprint. If we're worried about slowly overfilling small MCUs, we can > start another milestone for size-based optimizations we can make to > counteract these necessary changes. > > Matteo > > On Mon, May 4, 2026, 5:27 PM Tomek CEDRO <[email protected]> wrote: > > > +1 :-) Standard is standard, as a project we need to adhere, if a > > developer wants to do something else it's up to them, but project > > needs to stay standard compliant by default :-) > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > On Mon, May 4, 2026 at 3:18 PM raiden00pl <[email protected]> wrote: > > > > > > > The thing is - in my opinion - that interpretation of "strict POSIX > > > > compliance" is application-dependent. > > > > > > I don't think so, standardization doesn't work that way. In fact, it is > > the > > > opposite: > > > the standard is the main set of requirements on which all the rest is > > built. > > > If a standard states that X must be Y, then you meet the standard if X > > is Y. > > > If X is not Y, then you don't meet the standard. The application is not > > > subject > > > to the POSIX standard, the subject of the POSIX standard is the OS > > > interface. > > > So it doesn't matter if your application uses 32 bit time or not, > time_t > > > has to be > > > 64 bit to be compliant with the standard. > > > > > > pon., 4 maj 2026 o 16:57 Michal Lenc <[email protected]> > napisał(a): > > > > > > > But that's not caused by Xiang's merge request, the support is > already > > > > broken from what I understood from Greg's messages, right? > > > > > > > > To be fair, I am not 100 % convinced if we should go into too much > > > > trouble to support these archaic platforms. On one hand it's cool to > > > > have those, because not many platforms support them, on the other it > > can > > > > be a real pain from the maintenance and codebase clearance point of > > view. > > > > > > > > Having a portable layer that would provide the interface for 8/16 bit > > > > platforms could be a solution if we find someone willing to maintain > > it, > > > > but I think it should be solely for those platforms and not used from > > > > 32/64 bit microcontrollers because of code simplicity. Because this > > > > isn't just time related, but I suppose there are incompatible issues > > > > with other POSIX interfaces as well. > > > > > > > > Michal > > > > > > > > On 5/4/26 16:23, Tomek CEDRO wrote: > > > > > 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. > > > > >>>>> > > > > > > > > > > >
