[Bug 255290] _POSIX_C_SOURCE=200809 hides static_assert

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255290

Olivier Certner <olivier.freebsd at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olivier.freebsd at free.fr

--- Comment #12 from Olivier Certner <olivier.freebsd at free.fr> ---
(In reply to Garrett Wollman from comment #5)
(In reply to Warner Losh from comments #1, #7 and #11)

I think that what others are suggesting for static_assert is perfectly
admissible, and that you are over-interpreting the standard.

To be precise, I'm quoting text from IEEE Std 1003.1-2017, which is the Open
Group Base Specifications Issue 7, in the 2018 edition (there is no such thing
as POSIX-2018, rather, we are talking about POSIX.1-2017), document also
referenced as SUSv4 2018 edition, the latest one downloadable from the Open
Group site.

Some quotes from Base definitions (XBD), chapter 2: "Conformance"

> 2.1 Implementation Conformance
> 2.1.1 Requirements
> 2.1.1.4
> The system may provide non-standard extensions. These are features not
> required by POSIX.1-2017 and may include, but are not limited to:
>  * Additional functions
>  * Additional headers
>  * Additional symbols in standard headers
> (snip)
> Non-standard extensions of the utilities, functions, or facilities
> specified in POSIX.1-2017 should be identified as such in the system
> documentation. Non-standard extensions, when used, may change the
> behavior of utilities, functions, or facilities defined by POSIX.1-2017.
> The conformance document shall define an environment in which an
> application can be run with the behavior specified by POSIX.1-2017.
> In no case shall such an environment require modification of a Strictly
> Conforming POSIX Application (see Strictly Conforming POSIX Application).

>From here, it seems clear that adding functionality in standard headers is
allowed. Doing so is defining non-standard extensions. I concede that macros
and keywords are not explicitly mentioned in the list above, but I think the
spirit is that they are included as well.

It would be possible for FreeBSD to state that the environment supporting
strictly conforming C applications is one where no other standard than C99, if
any, is specified to 'cc', and that the application must define
__POSIX_C_SOURCE, but must not modify any symbol indicating the ISO C standard
used.

Conversely, requiring C11 at compile-time is an extension whose behavior can be
specified by the system. And the minimal specification is to require POSIX
behavior except for the differences introduced by C11.

> The following should be a strictly conforming, even if compiled
> with C11 compiler, as there's no exception in POSIX for newer versions
> of C introducing new things. The requested change would make it not be.

I don't think there is anything in the standard saying that a strictly
conforming application can be compiled with a C11 compiler. And although
defining __POSIX_C_SOURCE is required of strictly conforming applications,
doing so alone does not force an application to be strictly conforming (again,
nothing in the standard says or implies so, correct me if I'm wrong). On the
contrary, as quoted above, the system environment in which a conforming
application can be run with strict POSIX behavior has to be defined in the
conformance document of the system (FreeBSD).

So this is not a matter of standards, this is a matter of policy.

And because:
1. Other widely-used systems are doing so,
2. And in accordance with the motto "Be liberal in what you accept",
I'll argue that the most reasonable path, from the application support point of
view, would be for FreeBSD to follow suit.

-- 
You are receiving this mail because:
You are the assignee for the bug.