Hi Mateusz, Yes, you are correct, it was implicitly 32-bit: "because early Unix implementations were built on 32-bit hardware architectures (like the PDP-11 and VAX), operating system vendors universally implemented time_t as a signed 32-bit integer (long)"
[image: image.png] So, as Nathan pointed out, if we define POSIX.1-1988 we are not against POSIX definition, because this version didn't enforce time_t size. BR, Alan On Thu, Jul 9, 2026 at 7:14 AM raiden00pl <[email protected]> wrote: > POSIX never defined time as 32-bit. Older versions of POSIX simply didn't > touch on this issue, allowing for freedom in implementation. The increase > in > memory usage isn't primarily due to newer POSIX versions, but rather to > the fact that the first releases of NuttX didn't support all interfaces and > features > defined by the standard. Selecting a POSIX version from Kconfig won't help > here. > Selecting a POSIX profile may help (PSE51/PSE52), but the better option > is to disable POSIX features from Kconfig (like it's done now) and make > NuttX > POSIX-incompatible at the user's request. Fine-tuning has always been a > great > feature of NuttX and still is, it just requires a little work from the > user. > > czw., 9 lip 2026 o 01:44 Nathan Hartman <[email protected]> > napisał(a): > > > Well maybe there are opportunities to shrink the code size & stack usage > > without compromising on POSIX. > > > > Idea: just as C/C++ compilers allow you to choose the standard version > > (e.g., we choose ISO C90 even though it was superseded several times, > C99, > > C11, C23), we can consider letting NuttX users choose which POSIX version > > they want. So they can choose an older version that has fewer > requirements > > and get smaller code size. This idea honors the INVIOLABLES: strict POSIX > > compliance, and also honors the INVIOLABLES: all users matter, including > > users who want to use older POSIX standard. Want a 32-bit time_t? Choose > > the older POSIX standard in Kconfig. > > > > > > On Wed, Jul 8, 2026 at 11:53 AM Alan C. Assis <[email protected]> wrote: > > > > > Hi Greg, > > > > > > True, unfortunately we didn't pay too much attention to how the size > was > > > increasing. > > > Actually only one or two people doing review used to request to show > the > > > size increase on some PRs, although they appear small (few bytes or few > > > dozens of bytes, now to tens of KBs). > > > > > > At least now we will spot any increase automatically thanks to > MemBrowse > > > integration on our github. > > > > > > BR, > > > > > > Alan > > > > > > On Wed, Jul 8, 2026 at 12:37 PM Gregory Nutt <[email protected]> > > wrote: > > > > > > > If we are 2Kb short of 64Kb, then we are already at that threshold of > > > 64Kb > > > > support. You probably cannot make a legitimate application that > > actually > > > > does anything on the effected platforms now. A 2Kb savings now would > > > only > > > > be a stopgap measure as the size will certainly continue to grow and > > will > > > > likely consume that freed 2Kb in a few months. What would you do > > then? > > > > Put in another POSIX compliancy to work around the addition al size. > > > > > > > > It seems to me that unless there is an effort with larger scope than > > this > > > > then we can write off 64Kb support either now or in the next few > months > > > but > > > > bad bandages. Bandages will not do the job in the long term. In the > > > long > > > > term they only corrupt the POSIX compliancy and the clean design. > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > From: Alan C. Assis <[email protected]> > > > > Sent: Wednesday, July 8, 2026 6:27 AM > > > > To: [email protected] <[email protected]> > > > > Cc: Tiago Medicci Serrano <[email protected]> > > > > Subject: Re: Make NuttX Tiny Again (pun intended) > > > > > > > > Exactly! That is the point! > > > > > > > > It will be an option for people using MCUs with < 64KB Flash memory. > > > Thank > > > > you Karel. > > > > > > > > My suggestion add inside: > > > > RTOS Features --> > > > > [*] Disable NuttX interfaces > > > > [*] Disable POSIX Compatibility (default N and depends on > > > > DEFAULT_SMALL) > > > > Only after this option user will be able to disable TIME64 > > and > > > > LIBC_LONG_LONG > > > > > > > > Also, I think the "DEFAULT_SMALL" symbol is a confusing name, I > suggest > > > > renaming it to "SMALL_KERNEL" or similar. > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On Wed, Jul 8, 2026 at 10:07 AM Karel Kočí <[email protected]> wrote: > > > > > > > > > Hi > > > > > > > > > > My two cents: > > > > > > > > > > * Nobody is suggesting to break POSIX compatibility for everyone. > > > Alan's > > > > > suggestion is to have option to break it to reduce the size. > > > > > * It might be worth it to explicitly track chips that do support > > POSIX > > > in > > > > > NuttX > > > > > fully and those that need compromises. > > > > > > > > > > Just two cents.. > > > > > Karel > > > > > > > > > > > > > > > On Wed 08 Jul 2026 07:49:10 AM , Tiago Medicci Serrano wrote: > > > > > > Hi! > > > > > > > > > > > > I don't think NuttX getting bigger is an issue at all. Of course, > > we > > > > > should > > > > > > care about code size: this is an important metric to be aware of, > > and > > > > we > > > > > > should avoid unnecessary code. > > > > > > > > > > > > This is not the case here. The recent code changes are required > to > > be > > > > > > compatible with modern POSIX systems. Removing them just to fit > on > > > > > smaller > > > > > > MCUs would be intentionally making NuttX worse just to make it > fit > > > into > > > > > > MCUs that we don't have any usage analytics for. > > > > > > > > > > > > Systems evolve. Linux kernel is deprecating support for older > CPUs. > > > > > > > > > > > > People use NuttX because it's POSIX-compatible and the burden of > > > > > migrating > > > > > > applications is lower: that's the goal we should pursue first, > > IMHO. > > > > > > People use Zephyr for other reasons. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Em ter., 7 de jul. de 2026 às 17:08, Alan C. Assis < > > > [email protected]> > > > > > > escreveu: > > > > > > > > > > > > > I know it was discussed a lot, but I think removing > > > > > CONFIG_LIBC_LONG_LONG > > > > > > > alone (because TIME64) added about 2KB: > > > > > > > > > > > > > > Current mainline: > > > > > > > > > > > > > > $ arm-none-eabi-size nuttx > > > > > > > text data bss dec hex filename > > > > > > > 64008 1548 3996 69552 10fb0 nuttx > > > > > > > > > > > > > > Before https://github.com/apache/nuttx/pull/18840 (at commit > > > > > > > 4f6e695f7c56aa5a321008ca8e5ddd47e1959e4d) : > > > > > > > > > > > > > > $ arm-none-eabi-size nuttx > > > > > > > text data bss dec hex filename > > > > > > > 61936 1548 3764 67248 106b0 nuttx > > > > > > > > > > > > > > For 64KB Flash, these 2KB doesn't appear too much, but consider > > > that > > > > > these > > > > > > > are 2KB that we never can get rid of. > > > > > > > > > > > > > > So, few years ago NuttX was able to fit inside a 32KB and 4KB > RAM > > > > MCU: > > > > > > > (LPC1114FN28: > > > > > > > > https://www.flickr.com/photos/79703543@N00/18013069041/sizes/l/ > > ) > > > > > > > > > > > > > > If we keep increasing at this rhythm very soon people will have > > > > another > > > > > > > reason to use Zephyr: https://gzm-emb.com/blog/zephyr-16kb/ > (in > > > this > > > > > > > example it was 105KB Flash and 16KB, so we still have hope). > > > > > > > > > > > > > > The same way we reconsidered the signals, I think we should > give > > > the > > > > > user > > > > > > > the option to disable TIME64 and LIBC_LONG_LONG and run NuttX > on > > > > small > > > > > MCUs. > > > > > > > > > > > > > > BR, > > > > > > > > > > > > > > Alan > > > > > > > > > > > > > > On Tue, Jul 7, 2026 at 12:17 PM Alan C. Assis < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > >> Hi Michael, > > > > > > >> > > > > > > >> Thank you very much, in fact the printf implementation that > > NuttX > > > > uses > > > > > > >> currently was contributed by Keith Packard himself some years > > ago. > > > > > > >> > > > > > > >> But I don't know how it compares to his new picolibc. > > > > > > >> > > > > > > >> BR, > > > > > > >> > > > > > > >> Alan > > > > > > >> > > > > > > >> On Tue, Jul 7, 2026 at 11:50 AM Michael Jung < > > > > [email protected]> > > > > > > >> wrote: > > > > > > >> > > > > > > >>> Hi Alan, all, > > > > > > >>> > > > > > > >>> I believe picolibc has a very size efficient implementation > of > > > > printf > > > > > > >>> and scanf. See Keith's talk > > > > > https://www.youtube.com/watch?v=e3Vxr0iLIUE > > > > > > >>> at minute 13:06. > > > > > > >>> > > > > > > >>> Bye, > > > > > > >>> Michael > > > > > > >>> > > > > > > >>> On Tue, Jul 7, 2026 at 4:33 PM Alan C. Assis < > > [email protected]> > > > > > wrote: > > > > > > >>> > > > > > > >>>> Hi Everyone, > > > > > > >>>> > > > > > > >>>> Seems like we NuttX got great in the last few years. > > > > > > >>>> > > > > > > >>>> Although in general it is still using very little RAM memory > > and > > > > it > > > > > > >>>> uses a lot of Flash. > > > > > > >>>> > > > > > > >>>> So, even boards with 64KB of Flash are breaking: > > > > > > >>>> > > > > > > >>>> > > > > > > > > > > > > > > > ==================================================================================== > > > > > > >>>> > > > > > > >>>> Cmake in present: > > > > > > >>>> nucleo-f302r8/ihm07m1_b16,CONFIG_ARM_TOOLCHAIN_GNU_EABI > > > > > > >>>> Configuration/Tool: > > > > > > >>>> nucleo-f302r8/ihm07m1_b16,CONFIG_ARM_TOOLCHAIN_GNU_EABI > > > > > > >>>> 2026-07-07 13:44:43 > > > > > > >>>> > > > > > > > > > > > > > > > ------------------------------------------------------------------------------------ > > > > > > >>>> > > > > > > >>>> Cleaning... > > > > > > >>>> Configuring... > > > > > > >>>> Select HOST_LINUX=y > > > > > > >>>> TOOLS_DIR path is "/github/workspace/sources/nuttx" > > > > > > >>>> HOST = Linux > > > > > > >>>> Disabling CONFIG_ARM_TOOLCHAIN_GNU_EABI > > > > > > >>>> Enabling CONFIG_ARM_TOOLCHAIN_GNU_EABI > > > > > > >>>> Building NuttX... > > > > > > >>>> TOOLS_DIR path is "/github/workspace/sources/nuttx" > > > > > > >>>> HOST = Linux > > > > > > >>>> [1/5] cd > /github/workspace/sources/nuttx/build/libs/libc/misc > > && > > > > > > >>>> /usr/local/bin/cmake -E touch > > > > > > >>>> /github/workspace/sources/nuttx/libs/libc/misc/lib_utsname.c > > > > > > >>>> [2/5] Linking C executable nuttx > > > > > > >>>> FAILED: nuttx > > > > > > >>>> : && /tools/ccache/bin/arm-none-eabi-gcc --specs=nosys.specs > > > > > > >>>> -Wl,--print-memory-usage -Wl,--entry=__start -nostdlib > > > > > -Wl,--gc-sections > > > > > > >>>> -Wl,--cref -Wl,-Map=nuttx.map @CMakeFiles/nuttx.rsp -o nuttx > > && > > > : > > > > > > >>>> > > > > > > > > > > > > > > > /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: > > > > > > >>>> nuttx section `.data' will not fit in region `flash' > > > > > > >>>> > > > > > > > > > > > > > > > /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: > > > > > > >>>> region `flash' overflowed by 4 bytes > > > > > > >>>> Memory region Used Size Region Size %age Used > > > > > > >>>> flash: 65540 B 64 KB 100.01% > > > > > > >>>> sram: 5556 B 16 KB 33.91% > > > > > > >>>> collect2: error: ld returned 1 exit status > > > > > > >>>> ninja: build stopped: subcommand failed. > > > > > > >>>> cp: cannot stat 'nuttx.hex': No such file or directory > > > > > > >>>> cp: cannot stat 'nuttx.bin': No such file or directory > > > > > > >>>> cp: cannot stat 'nuttx.hex': No such file or directory > > > > > > >>>> cp: cannot stat 'nuttx.bin': No such file or directory > > > > > > >>>> /github/workspace/sources/nuttx > > /github/workspace/sources/nuttx > > > > > > >>>> > > > > > > >>>> It is important to notice that CONFIG_DEFAULT_SMALL is > already > > > > > defined > > > > > > >>>> to it. > > > > > > >>>> > > > > > > >>>> Analyzing the 20 biggest functions there is not a single > > > culprit, > > > > so > > > > > > >>>> probably we need to reduce the overall functions size: > > > > > > >>>> > > > > > > >>>> $ arm-none-eabi-nm --print-size --size-sort --radix dec -C > > > nuttx | > > > > > grep > > > > > > >>>> ' [TtWw] ' | tail -20 > > > > > > >>>> 134243508 00000390 t pwm_configure > > > > > > >>>> 134217728 00000392 T _vectors > > > > > > >>>> 134229344 00000396 t adc_read > > > > > > >>>> 134249208 00000400 t file_vioctl > > > > > > >>>> 134218408 00000424 T stm32_configgpio > > > > > > >>>> 134269892 00000448 T motor_aobserver_nfo_b16 > > > > > > >>>> 134231544 00000448 t uart_writev > > > > > > >>>> 134239368 00000460 t stm32_foc_setup > > > > > > >>>> 134261888 00000468 T parse_args > > > > > > >>>> 134264176 00000500 T foc_motor_init > > > > > > >>>> 134263096 00000540 T foc_fixed16_thr > > > > > > >>>> 134256256 00000540 T nxsig_tcbdispatch > > > > > > >>>> 134233432 00000540 t uart_ioctl > > > > > > >>>> 134265056 00000612 T foc_motor_control > > > > > > >>>> 134265668 00000648 T foc_motor_handle > > > > > > >>>> 134231992 00000652 t uart_readv > > > > > > >>>> 134260828 00000692 T foc_main > > > > > > >>>> 134252412 00000700 T __udivmoddi4 > > > > > > >>>> 134245448 00000860 t nsh_parse_command > > > > > > >>>> 134258408 00001234 t vsprintf_internal.constprop.0 > > > > > > >>>> > > > > > > >>>> I can't resist to ask the Claude to analyze these data, and > it > > > > gave > > > > > us > > > > > > >>>> some picture of current code tree: > > > > > > >>>> > > > > > > >>>> [image: image.png] > > > > > > >>>> > > > > > > >>>> And seems like NSH and printf (vsprintf) are the biggest > > > > offenders: > > > > > > >>>> > > > > > > >>>> [image: image.png] > > > > > > >>>> > > > > > > >>>> So, if someone has some suggestions on how we can improve > this > > > > > > >>>> scenario, please let me know. > > > > > > >>>> > > > > > > >>>> At least now we have the option to disable some important > > > features > > > > > like > > > > > > >>>> signals (that unfortunately will break POSIX compatibility). > > But > > > > > maybe we > > > > > > >>>> can apply some diet to NSH and printf to improve it. > > > > > > >>>> > > > > > > >>>> BR, > > > > > > >>>> > > > > > > >>>> Alan > > > > > > >>>> > > > > > > >>> > > > > > > > > > > > > > > >
