From owner-freebsd-standards@freebsd.org Wed Apr 21 21:49:19 2021 Return-Path: Delivered-To: freebsd-standards@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3889A5F2ACE for ; Wed, 21 Apr 2021 21:49:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4FQZ2R0xrGz4Wmc for ; Wed, 21 Apr 2021 21:49:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1EA6B5F2B3C; Wed, 21 Apr 2021 21:49:19 +0000 (UTC) Delivered-To: standards@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1E6775F2ACD for ; Wed, 21 Apr 2021 21:49:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FQZ2R0F3Lz4WZj for ; Wed, 21 Apr 2021 21:49:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id EF2DF5933 for ; Wed, 21 Apr 2021 21:49:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 13LLnIP7006028 for ; Wed, 21 Apr 2021 21:49:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 13LLnIOm006027 for standards@FreeBSD.org; Wed, 21 Apr 2021 21:49:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 255290] _POSIX_C_SOURCE=200809 hides static_assert Date: Wed, 21 Apr 2021 21:49:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: olivier.freebsd@free.fr X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 21:49:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255290 Olivier Certner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olivier.freebsd@free.fr --- Comment #12 from Olivier Certner --- (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.=