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.

Greg

Reply via email to