Date: Wed, 21 Apr 2021 21:49:19 +0000 From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 255290] _POSIX_C_SOURCE=200809 hides static_assert Message-ID: <bug-255290-99-7Vku9JP4S2@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-255290-99@https.bugs.freebsd.org/bugzilla/> References: <bug-255290-99@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255290 Olivier Certner <olivier.freebsd@free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olivier.freebsd@free.fr --- Comment #12 from Olivier Certner <olivier.freebsd@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 th= ing 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 stand= ard used. Conversely, requiring C11 at compile-time is an extension whose behavior ca= n 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 (aga= in, 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 poin= t of view, would be for FreeBSD to follow suit. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255290-99-7Vku9JP4S2>