Date: Thu, 22 Apr 2021 07:58:27 +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-r2cNDSZ7FX@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 --- Comment #16 from Olivier Certner <olivier.freebsd@free.fr> --- (In reply to Warner Losh from comment #13) > It's a case of doing exactly what the standard specifies, and nothing mor= e. The standard doesn't specify that. In particular, as said above, it never s= ays that defining _POSIX_C_SOURCE is enough to obtain a strictly POSIX environm= ent. And more precisely, it says this, which directly answers our concern: > 2.2 The Compilation Environment > 2.2.1 POSIX.1 Symbols > Certain symbols in this volume of POSIX.1-2017 are defined in > headers (see XBD Headers). Some of those headers could also define > symbols other than those defined by POSIX.1-2017, potentially > conflicting with symbols used by the application. Also, POSIX.1-2017 > defines symbols that are not permitted by other standards to appear > in those headers without some control on the visibility of those symbols. > Symbols called "feature test macros" are used to control the visibility > of symbols that might be included in a header. Implementations, future > versions of this standard, and other standards may define additional > feature test macros. > (snip) > The _POSIX_C_SOURCE Feature Test Macro > (snip) > When an application includes a header described by POSIX.1-2017, > and when this feature test macro is defined to have the value 200809L: > 1 All symbols required by POSIX.1-2017 to appear when the header is > included shall be made visible. > 2 Symbols that are explicitly permitted, but not required, by > POSIX.1-2017 to appear in that header (including those in reserved name > spaces) may be made visible. > 3 Additional symbols not required or explicitly permitted by > POSIX.1-2017 to be in that header shall not be made visible, except when > enabled by another feature test macro. So yes, it's possible to define additional macros under a feature test macr= o. > There's no feature test macro defined for sources to say they want a C11 > extensions in addition to the strict posix environment requested by > __POSIX_C_SOURCE__ =3D 200809. As quoted above, an implementation is free to define any feature test macro they wish. So, compiling with C11 with appropriate flags on the command-line should automatically define some feature test macro, and then we'll be stan= dard compliant. > glibc choses to enable this by default, but it's unclear that's standard > conformant. It is standard conformant. The standard says that conformant programs shoul= d be built with c99, not cc (I could not find references to cc in the standard),= so it seems clear (to me at least) that the default C standard supported by cc= is irrelevant to this discussion. > https://reviews.freebsd.org/D29902 Thanks. Commenting there. --=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-r2cNDSZ7FX>