But option 2 has the global effect, which can't handle the mix usage at the same time that some apps need NuttX definition, others need self definition?
On Fri, Oct 9, 2026 at 7:13 PM Marco C. <[email protected]> wrote: > Hello, > > NuttX public headers define some plain names (not reserved for the > implementation) in every program that includes them. A valid C program > that uses one of these names as its own identifier does not compile on > NuttX. > > The names: > > - <sys/types.h>: OK and ERROR (enum constants). > - <errno.h>: set_errno() and get_errno() (macros). > - <nuttx/compiler.h>, which almost every public header includes: CODE, > FAR, NEAR, DSEG, IPTR, IOBJ, EXTERN, UNUSED, PRAGMA, and many > lowercase macros (88 across its compiler sections), for example > object_size(), weak_alias(), visibility_hidden, visibility_default, > builtin_function(), inline_function, printf_like(), > begin_packed_struct, return_address. > > Examples that are valid C but fail on NuttX: > > #include <stdio.h> > enum result { FAIL, OK }; /* 'OK' conflicts with a previous > declaration */ > static int CODE = 3; /* CODE expands to nothing */ > enum vis { visibility_hidden }; /* expands to __attribute__((...)) */ > size_t object_size(void *p); /* macro needs 2 arguments */ > static void set_errno(int e); /* expands as the errno.h macro */ > > The NuttX tree and nuttx-apps use these names a lot (in apps: OK 2802 > times, ERROR 4504, FAR 17824), so a plain rename is not practical. > > Possible directions: > > 1. A per-program opt-out: when a program defines a macro (for example > NUTTX_NO_EXTENSION_NAMES, or when it asks for a strict standard > namespace with _POSIX_C_SOURCE/_XOPEN_SOURCE and __STRICT_ANSI__), the > public headers use reserved spellings internally and do not define the > plain names. Nothing changes for existing code. > 2. A Kconfig option, default y, to keep the plain names; with it off, > the public headers define only reserved names. NuttX and nuttx-apps > would continue to get the plain names from an internal header. > 3. Keep the names, and document them as reserved on NuttX. > > Today I work around it in ported programs with a forced-include header > that #undef the names after the system headers. That cannot fix > OK/ERROR, which are enum constants. > > Which direction is acceptable? I can do the work for 1 or 2. > > Thanks, > Marco Casaroli >
