From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2C46C3858CDB; Thu, 18 Jan 2024 21:11:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C46C3858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1705612268; bh=ktL5f56j4cymqZmGd08sOG/nSBSlyFi2kTj4QJKdDyw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vluSbNThreemRM/Z+04+K5qfV9KxJtfwidrc0HJmggiJuzxkqpD4l9LLURT1LBc7/ mARFXvjx9SkWwJcRqgU3epm7Gn0mq3DIJIIR5sfWJpxQBcCbd4Dhua3Vqk/jCWU0XS 55zOKE9YlY+AOVgWd/ut3aJOqG92WwCnoXMIU/hQ= From: "sandra at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/111287] doc: "strict ISO mode" definition is not up-to-date Date: Thu, 18 Jan 2024 21:11:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Version: 13.2.0 X-Bugzilla-Keywords: documentation X-Bugzilla-Severity: normal X-Bugzilla-Who: sandra at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111287 sandra at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- I think the problem here goes beyond this one line of documentation. E.g, there's a reference to "strict ISO C90 mode" later in the same paragraph th= at probably ought to refer to any later C standard as well, and it's not clear whether "Outside strict ISO C mode" means that these builtins are always available in C++. (IOW, does strict ISO C mode disable things that are otherwise normally supported by C-family dialects, or do non-strict ISO C m= ode enable things that are normally are *not* supported?) Re __STRICT_ANSI__, invoke.texi only says that is defined when -ansi is use= d, so either defining it for all those later standards is wrong or the documentation is wrong (and it needs to be moved out of the description of = the -ansi option). I think we at least need a formal definition in the manual of what "strict = ISO mode" means, for both C and C++, and to implement/document additional #defi= nes for different dialects. It's probably too late to fix __STRICT_ANSI__, tho= ugh. In any case, I think the standards compliance section, the -std=3D options documentation, and the builtins section all need to be made consistent.=