Ok, makes sense, thank you Mateusz! BR,
Alan On Sun, May 3, 2026 at 1:15 PM raiden00pl <[email protected]> wrote: > From what I understand, the lack of standardization for time_t was one > of POSIX's biggest problems, one that many smart people complained about. > Now that it's standard, we should be happy. It's even easier to create > portable > applications :) > > Of course it has its costs, but there's nothing we can do about it. If > someone > needs to trim memory for small systems, they can always do so by modifying > the kernel in their own repo. For a 32-bit ARM that hasn't previously used > 64-bit > in the code, this will add about 700 bytes of flash. I've checked this > before. > > niedz., 3 maj 2026 o 18:10 Xiang Xiao <[email protected]> > napisał(a): > > > If you disable signal, and call some of the signal functions, the > compiler > > and linker will report the error directly. > > but 32/64bit time_t/clock_t report the error only after your devices run > > more than several days/weeks/months. > > so, I prefer to remove Kconfig to avoid the runtime error and more > > compatible with POSIX. > > here is the size change before and after > > https://github.com/apache/nuttx/pull/18840 on stm32f4discovery:nsh: > > | Section | master | PR | Δ bytes | Δ % | > > | ------------------ | -----: | ----: | -----: | ----: | > > | `.text` | 84 376 | 85 056 | **+680** | +0.81 % | > > | `.ARM.exidx` | 8 | 8 | 0 | 0.00 % | > > | `.data` | 884 | 888 | +4 | +0.45 % | > > | `.bss` | 4 504 | 4 600 | +96 | +2.13 % | > > | `.comment` | 68 | 68 | 0 | 0.00 % | > > | `.ARM.attributes` | 44 | 44 | 0 | 0.00 % | > > | `.debug_frame` | 428 | 496 | +68 | +15.9 % | > > | `.debug_line_str` | 216 | 216 | 0 | 0.00 % | > > | **Total (sum)** | 90 528 | 91 376 | **+848** | +0.94 % | > > > > > > > > On Sun, May 3, 2026 at 10:13 PM Alan C. Assis <[email protected]> wrote: > > > > > Exactly, but the point is: if we can fix it now, why to merge a PR and > > > later spend time adding it back to Kconfig ? > > > > > > See the "signal" history as an example, it was removed some years ago, > > and > > > then we spent a lot of time and energy discussing how to return with it > > (at > > > least partial signal disable). > > > > > > I think just changing the Kconfig to CONFIG_SYSTEM_TIME64 default Y > will > > > fix the issue since all boards will have it be default and only someone > > > willing to run NuttX on some small MCU or retro hardware can disable > it. > > > > > > This way is better than removing the support to TIME 32-bit all > together. > > > > > > BR, > > > > > > Alan > > > > > > On Sun, May 3, 2026 at 10:47 AM Matteo Golin <[email protected]> > > > wrote: > > > > > > > Size could be a valid concern. We can always add the ability to go > back > > > to > > > > 32 bit time in Kconfig. Does this have any concerns with violating > > POSIX? > > > > I'd imagine not, given that it used to be 32 bit. > > > > > > > > On Sun, May 3, 2026, 9:33 AM Alan C. Assis <[email protected]> > wrote: > > > > > > > > > Hi Matheusz, > > > > > > > > > > Thank you , so probably I forgot about this discussion. Sorry Xiang > > for > > > > > raising this Discussion, but I thought it wasn't discussed before. > > > > > > > > > > Anyway I think we need to see how much it will increase in > Flash/RAM. > > > > > > > > > > If it increases "a lot" (more than 700 bytes), maybe we should keep > > > this > > > > > config and just make it default Y, because people could use NuttX > on > > > > small > > > > > microcontrollers that could be left behind with this change. > > > > > > > > > > This is part of the "The Inviolable Principles of NuttX: All Users > > > > Matter", > > > > > especially that part: > > > > > - > > > > > > > > > > *Hobbyists are valued users of the OS including retro computing > > > hobbyists > > > > > and DIY “Maker” hobbyists.* > > > > > In the past we already did drastic modifications that increased > NuttX > > > > size > > > > > and now we are trying to figure out how to fix what we did. > > > > > > > > > > BR, > > > > > > > > > > Alan > > > > > > > > > > On Sun, May 3, 2026 at 9:17 AM raiden00pl <[email protected]> > > > wrote: > > > > > > > > > > > 32 bit time is not compatible with the latest POSIX and it was > > > already > > > > > > agreed that this change would be included in release 13 in one of > > > > > > the previous discussions on this topic. We were just waiting for > > > > release > > > > > > 13. > > > > > > > > > > > > niedz., 3 maj 2026 o 13:52 Alan C. Assis <[email protected]> > > > > napisał(a): > > > > > > > > > > > > > Hi Everyone, > > > > > > > I want to bring this PR to your attention: > > > > > > > https://github.com/apache/nuttx/pull/18840 > > > > > > > > > > > > > > I have some concerns like those added to my Change Request > there. > > > > > > > > > > > > > > I think broad modifications like this need to be discussed with > > our > > > > > > > community. > > > > > > > > > > > > > > I'm not against this PR, it will avoid the 2038 Unix Epoch BUG, > > but > > > > it > > > > > is > > > > > > > important to know first the impact of this commit to small > > > > > > > microcontrollers. > > > > > > > > > > > > > > Unfortunately we don't have how many bytes this PR will > > add/remove > > > > > > to/from > > > > > > > Flash and RAM. > > > > > > > > > > > > > > Also we discussed many times that all PRs need to include valid > > > > > testing, > > > > > > > just "checkpatch.sh -f" is not a real test, it doesn't > guarantee > > > that > > > > > the > > > > > > > PR will pass in the CI. > > > > > > > > > > > > > > In cases like this where a PR modifies many boards and MCUs, a > > good > > > > > idea > > > > > > it > > > > > > > to test it on your own github account first, before submitting > > the > > > > PR, > > > > > as > > > > > > > explained here: https://github.com/apache/nuttx/issues/18568 > > > > > > > > > > > > > > This is not a criticism of the author, that is my friend, but > it > > is > > > > > > > important that we improve our process. Seems like we are still > > > > messing > > > > > > with > > > > > > > basic things. > > > > > > > > > > > > > > BR, > > > > > > > > > > > > > > Alan > > > > > > > > > > > > > > > > > > > > > > > > > > > >
