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