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