raiden00, that could be an option, although I think it is a drastic option :-)
Remember that even PSE51/52 requires time() and time_t, but doesn't require time_t equal to 64-bit (because it is based on IEEE Std 1003.13-2003). Maybe it can change in the future, but currently time_t is not required to be 64-bit for PSE51/52. So we could have CONFIG_POSIX_SUBSET_PSE51 or _PSE52 and allow CONFIG_SYSTEM_TIME64 be disabled. BR, Alan On Mon, May 4, 2026 at 12:40 PM raiden00pl <[email protected]> wrote: > 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. > > > > > >>>>> > > > > > > > > > > > > > > > >
