posix: implementation conformance macros defined on command line instead of in unistd.h

[cfriedt]

Describe the bug

@nordicjm believes that there is a bug in that POSIX implementation conformance macros[1] (aka feature test macros) are defined on the command line instead of in unistd.h.

I.e. we have -D_POSIX_THREADS=200809L when CONFIG_POSIX_THREADS=y, -D_POSIX_SEMAPHORES=200809L when CONFIG_POSIX_SEMAPHORES=y, etc.

In fact, our configuration system has been designed this way, so there is precedent in the tree already and it has gone through peer review.

But, the POSIX specification does state that feature test macros are defined in unistd.h.

By the letter of the standard, that is true. However, one would also note, that even Picolibc, and Newlib, arcmwdt, etc, do not define feature test macros (other than for RTEMS and XMK) in their unistd.h files. In fact, it would be nearly impossible to do that statically for Zephyr since all of these features are configurable at build time.

@nordicjm said that his desired alternate approach would be to generate unistd.h at build time.

That might work, so it's probably worth a try. However, it should be noted that most of the unistd.h files that we use are not defined in the Zephyr repository, but in other public (and in some cases private) repositories.

[1] Note, there is a difference between implementation conformance macros and application conformance macros; implementation conformance macros are defined by the system, and application conformance macros are defined by the application.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html

Regression

• This is a regression.

Steps to reproduce

• west build -b native_sim samples/hello_world (actually, this does not reproduce the bug)
• west build -b native_sim tests/posix/common (which ... enables POSIX features...)

The argument was that "you do not need -D_XOPEN_STREAMS=700 to compile samples/hello_world so why is it defined??"

Of course, that feature test macro is not actually defined when compiling samples/hello_world. One needs to enable CONFIG_XSI_STREAMS (now CONFIG_XOPEN_STREAMS, since #97836 was reverted). So... one would need to enable the feature in order to observe the implementation conformance macro that signifies that the OS supports the feature that was requested... seems a bit cyclic to me.

In Picolibc, Newlib, arcmwdt, or other production C libraries, _XOPEN_STREAMS (or other feature test macros) would be defined in <sys/features.h>. Other C libraries or POSIX implementations might define them somewhere else.

If they are enabled then they would be visible to nearly all compilation artifacts.

I.e. it does not matter if they are defined on the command line or in an automatically-generated header somewhere.

There is a reason for that. In order to have a strictly conformant POSIX application (running on a strictly conformant POSIX system), compilation units must have a consistent view of POSIX features.

Relevant log output

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

No response

Additional Context

The impact of this bug It seems to be an annoyance that has been amped-up due to other frustrations.

That's fine. I'm happy to fix the bug if it should be considered a bug.

However, threatening to nack PRs #97152 and #97855 that deliver features for the next release that are highly desireable (rather than simply filing a bug and allowing the maintainer to fix the bug) seems like a retaliatory action.

I would be more than happy to fix the bug in the stabilization period.

[cfriedt]

I set this as low priority, since it doesn't really break anything, but would still like to address this issue in the stabilization period.

[nashif]

@cfriedt if needed, this should first go to the arch wg, not the TSC.