Hi Xiang, Thank you for this explanation and the delta increase size.
Ok, if everybody agrees it is fine to increase more than 800 bytes to stay compliant with POSIX (even if it means we are raising the bar for small MCUs) I am OK with it. BR, Alan On Sun, May 3, 2026 at 1:10 PM Xiang Xiao <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > >
