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