On Thu, Mar 19, 2020 at 9:12 PM Gregory Nutt <[email protected]> wrote:
>
>
> > depending on CONFIG_CAN_PASS_STRUCTS,
> > mallinfo has a different prototype.
> >
> > #ifdef CONFIG_CAN_PASS_STRUCTS
> > struct mallinfo mallinfo(void);
> > #else
> > int mallinfo(FAR struct mallinfo *info);
> > #endif
> >
> > and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
> > for this even in APPDIR.
> > i'd like to suggest to simplify this by always using
> > "int mallinfo(FAR struct mallinfo *info);" version.
> >
> > or, even "void mallinfo(FAR struct mallinfo *info);" because it
> > doesn't return any errors.
>
> We should not do that. There are contemporary toolchains that do not
> support passing structures or unions. Currently on the SDCC compiler
> cannot pass structures. SDCC is one variant of similar compilers
> focusing on small MCUs. I imagine that the others have similar
> limitations. Currently SDCC is used only with z80 but there has been
> talk of using it with other architectures as well, but those have not
> gone anywhere.
>
> Certainly, removing support for SDCC and related compiles would close a
> lot of door for not reason other than your personal preference. Certain
> the CONFIG_CAN_PASS_STRUCTS is ugly but it serves a real purpose for the
> community. Your proposal serves no purpose other than you personal
> preference.
>
> It is worth re-considering the INVIOLABLES.txt which all committers are
> expected to uphold:
>
> All Users Matter
> ----------------
>
> o All support must apply equally to all supported platforms. At
> present
> this includes Linux, Windows MSYS, Windows Cygwin, Windows Ubuntu,
> Windows native, macOS, Solaris, and FreeBSD. No tool/environment
> solutions will be considered that limit the usage of NuttX on
> any of
> the supported platforms.
> o Inclusive rather than exclusive.
> o *Hobbyists are valued users of the OS* including retro
> computing hobbyists
> * and DIY “Maker” hobbyists.
> o Supported toolchains: GCC, Clang, *SDCC*, ZiLOG ZDS-II (c89), IAR.
> Others?
> o No changes to build system should limit use of NuttX by any user.
> o *Simplifying things for one user does not justify excluding
> another user.*
> o *We should seek to expand the NuttX user base, not to limit it
> for**
> reasons of preference or priority.*
> o *We must resist the pull to make NuttX into a Linux-only,
> GCC-only, and**
> ARM-only solution.*
>
> I think we must think less about ourselves and less about our own
> project environment, and more about the community.
>
I suggest to remove CAN_PASS_STRUCTS not only because the code is
ulgy, the more important is that it break the 1st INVIOLABLES rule:
Strict POSIX compliance
-----------------------
o Strict conformance to the portable standard OS interface as defined at
OpenGroup.org.
o A deeply embedded system requires some special support. Special
support must be minimized.
o The portable interface must never be compromised only for the sake of
expediency.
o Expediency or even improved performance are not justifications for
violation of the strict POSIX interface
For example, we even change sigqueue prototype to work around the
compiler issue:
nuttx/include/signal.h:#ifdef CONFIG_CAN_PASS_STRUCTS
nuttx/include/signal.h-int sigqueue(int pid, int signo, union sigval value);
nuttx/include/signal.h-#else
nuttx/include/signal.h-int sigqueue(int pid, int signo, FAR void *sival_ptr);
nuttx/include/signal.h-#endif
It's great if we can support the noncompliant compiler without break
API prototype, but CONFIG_CAN_PASS_STRUCTS isn't a case.
BTW, SDCC dev fix this issue:
https://github.com/z88dk/z88dk/issues/1132
> Greg
>
