Date: Wed, 21 Apr 2021 19:38:06 +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-SUj8DeFPzJ@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 Eldred Habert <freebsdbugs@eldred.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsdbugs@eldred.fr --- Comment #10 from Eldred Habert <freebsdbugs@eldred.fr> --- (In reply to Warner Losh from comment #7) Hey, upstream here. Thank you very much Tobik both for reporting the issue = to us and here ^^ I interpret the following: > Additional symbols not required or explicitly permitted by IEEE Std 1003.= 1-2001 to be in that header shall not be made visible, except when enabled = by another feature test macro. ... as permitting the use of C11 functionality, since our codebase specifies the `-std=3Dgnu11` flag (which should be c11, but we had to switch to fix t= he build with DJGPP), itself defining __STDC_VERSION__ to request `static_asse= rt`. That point has been made already, and I disagree with the following reply to it: > I would interpret that as requesting undefined behavior. POSIX is C99 and= C99 only. You requested POSIX, and then requested something else also. Tha= t behavior is not defined. Pick one or the other, but you cannot have both = as there's no well-defined way to provide both. I don't read the snippet copied in Comment #6 as "POSIX requires C99 functionality, neither more nor less", but rather "POSIX does not aim to be https://xkcd.com/927/, thus definitions were aligned on C99 whenever possib= le". As far as I'm aware, C11 does not make any modifications to the standard th= at are incompatible with POSIX 2008, and thus there are no conflicts, and henc= e, no undefined behavior. I back this up by POSIX allowing other feature test macros to define symbols outside of POSIX's scope; if defining any other such macros would result in= UB, why would the standard explicitly allow it? --=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-SUj8DeFPzJ>