patacongo commented on pull request #3589: URL: https://github.com/apache/incubator-nuttx/pull/3589#issuecomment-828084853
> > > > I don't think **KERNEL** does anything in the FLAT build. > > Oh ok. In my case I had an issue with these lines in `stdlib.h` when building the C++ library: > > ```c > /* System() command is not implemented in the NuttX libc because it is so > * entangled with shell logic. There is an experimental version at > * apps/system/system. system() is prototyped here, however, for > * standards compatibility. > */ > > #ifndef __KERNEL__ > int system(FAR const char *cmd); > #endif > ``` Yes, this is a case where __KERNEL__ "kind of" does something in the FLAT build. system() is a standard interface defined in OpenGroup.org, but in the case of NuttX, it is NOT part of the OS. It is part of apps/ provided at apps/system/system. NuttX code should never depend on anything in apps/. That would be bad architecture: applications are built on top the OS and the OS must be independent of the application. Linux really has the same issue, but they mitigate the coupling via the file system. /bin/sh is the shell used by system() (I think, I should check) and /bin/sh might be a symbolic link to the real shell binary. So in this case, the __KERNEL__ conditioning is a feeble attempt at restricting things so that nothing under nuttx/ can call system() without at least a warning. But this is so feeble as to be useless and the conditioning could just as well be removed. From what you said above, this might actually provide some protection is __KERNEL__ is defined for all OS libraries under nuttx/ and not defined for libapps.a. But it is still pretty lame. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
