public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: gcc-patches@gcc.gnu.org
Cc: libstdc++@gcc.gnu.org
Subject: [PATCH] doc: Document that libstdc++ uses __STRICT_ANSI__
Date: Wed, 16 Dec 2020 13:27:48 +0000	[thread overview]
Message-ID: <20201216132748.GA1027090@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

Libstdc++ has been using __STRICT_ANSI__ for years, e.g. to decide
whether or not std::is_integral<__int128> should be true.

gcc/ChangeLog:

	* doc/cpp.texi (Common Predefined Macros): Mention that
	__STRICT_ANSI__ is used by libstdc++ too.

OK for trunk?

I'd also like to tell users they're not allowed to undefine the
macro, would that be acceptable, or is that supposed to work?

I don't see how it's possible to make it work with libstdc++ if users
do stupid things like:

#include <type_traits>
#undef __STRICT_ANSI__
#include <iterator>

This causes the library to be in an inconsistent (broken) state,
because some templates are defined according to strict ISO C++ rules
and then other templates are not, but assume the earlier definitions
are consistent.

We frequently see users doing -std=c++11 -U__STRICT_ANSI__ which makes
me smash my head on the table. Just use -std=gnu++11 and stop being
dumb.



[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1228 bytes --]

commit c516abe37ef82444e125b32933ea44a00a99d1ec
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Dec 16 13:21:24 2020

    doc: Document that libstdc++ uses __STRICT_ANSI__
    
    Libstdc++ has been using __STRICT_ANSI__ for years, e.g. to decide
    whether or not std::is_integral<__int128> should be true.
    
    gcc/ChangeLog:
    
            * doc/cpp.texi (Common Predefined Macros): Mention that
            __STRICT_ANSI__ is used by libstdc++ too.

diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 5dcd67259e3..c5cdd5cb069 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -1996,8 +1996,8 @@ testing @code{@w{(__GNUC__ && __cplusplus)}}.
 GCC defines this macro if and only if the @option{-ansi} switch, or a
 @option{-std} switch specifying strict conformance to some version of ISO C
 or ISO C++, was specified when GCC was invoked.  It is defined to @samp{1}.
-This macro exists primarily to direct GNU libc's header files to use only
-definitions found in standard C.
+This macro exists primarily to direct libstdc++ and GNU libc's header files
+to use only definitions found in standard C and C++.
 
 @item __BASE_FILE__
 This macro expands to the name of the main input file, in the form

                 reply	other threads:[~2020-12-16 13:27 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201216132748.GA1027090@redhat.com \
    --to=jwakely@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).