public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "giecrilj at stegny dot 2a.pl" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/59687] New: The description of ios::noreplace is hilarious Date: Sun, 05 Jan 2014 19:45:00 -0000 [thread overview] Message-ID: <bug-59687-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59687 Bug ID: 59687 Summary: The description of ios::noreplace is hilarious Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: giecrilj at stegny dot 2a.pl The page "Backwards Compatibility" [1] says: > For output streams, “nocreate” is probably the default, unless you specify std::ios::trunc ? Probably??? Could you please estimate the probability? Also inconsistent with the table at filebuf::open that does not mention "x" mode to be actually used. > To be safe, you can open the file for reading, check if it has been opened, and then decide whether you want to create/replace or not. This may be true when there is only one process and one thread; otherwise it is blatant disinformation and wishful thinking — see the page "C++ TOCTOU Vulnerability" in the CERT Secure Coding Manual [2]. ___ [1] <URL: http://gcc.gnu.org/onlinedocs/libstdc++/manual/backwards.html#backwards.third.nocreate_noreplace > [2] <URL: https://www.securecoding.cert.org/confluence/download/attachments/40402999/09%20Race%20Conditions.pdf > >From gcc-bugs-return-439103-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jan 05 19:46:49 2014 Return-Path: <gcc-bugs-return-439103-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 24292 invoked by alias); 5 Jan 2014 19:46:49 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 24272 invoked by uid 48); 5 Jan 2014 19:46:45 -0000 From: "pab at pabigot dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/59681] SVN 197248 adding N3582 support broke Boost.Regex with -std=c++1y Date: Sun, 05 Jan 2014 19:46:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pab at pabigot dot com X-Bugzilla-Status: NEW 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: Message-ID: <bug-59681-4-CZsMBXWQZN@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-59681-4@http.gcc.gnu.org/bugzilla/> References: <bug-59681-4@http.gcc.gnu.org/bugzilla/> 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 X-SW-Source: 2014-01/txt/msg00245.txt.bz2 Content-length: 969 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59681 --- Comment #3 from Peter A. Bigot <pab at pabigot dot com> --- But also note [dcl.type.simple] p4: The type denoted by decltype(e) is defined as follows: — if e is an unparenthesized id-expression or an unparenthesized class member access (5.2.5), decltype(e) is the type of the entity named by e. If there is no such entity, or if e names a set of overloaded functions, the program is ill-formed; — otherwise, if e is an xvalue, decltype(e) is T&&, where T is the type of e; — otherwise, if e is an lvalue, decltype(e) is T&, where T is the type of e; — otherwise, decltype(e) is the type of e. The operand of the decltype specifier is an unevaluated operand (Clause 5). which means decltype((e)) is not necessarily the same as decltype(e). Perhaps the change was made to make this work, but it has side effects in some context that does not (explicitly) use decltype. >From gcc-bugs-return-439104-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jan 05 19:54:17 2014 Return-Path: <gcc-bugs-return-439104-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 26193 invoked by alias); 5 Jan 2014 19:54:17 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 26177 invoked by uid 48); 5 Jan 2014 19:54:13 -0000 From: "giecrilj at stegny dot 2a.pl" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/59687] The description of ios::noreplace is hilarious Date: Sun, 05 Jan 2014 19:54:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: documentation X-Bugzilla-Severity: major X-Bugzilla-Who: giecrilj at stegny dot 2a.pl X-Bugzilla-Status: UNCONFIRMED 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: Message-ID: <bug-59687-4-ZHHdGkWs7v@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-59687-4@http.gcc.gnu.org/bugzilla/> References: <bug-59687-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg00246.txt.bz2 Content-length: 337 http://gcc.gnu.org/bugzilla/show_bug.cgi?idY687 --- Comment #1 from Christopher Yeleighton <giecrilj at stegny dot 2a.pl> --- (In reply to Christopher Yeleighton from comment #0) > Also inconsistent with the table at filebuf::open that does not mention "x" > mode to be actually used. Oops, scratch that, I had "noreplace" in mind.
next reply other threads:[~2014-01-05 19:45 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-01-05 19:45 giecrilj at stegny dot 2a.pl [this message] 2014-01-06 17:35 ` [Bug libstdc++/59687] " redi at gcc dot gnu.org 2014-01-10 14:31 ` redi at gcc dot gnu.org 2014-01-10 14:33 ` redi at gcc dot gnu.org 2014-01-11 12:30 ` giecrilj at stegny dot 2a.pl 2014-01-11 12:57 ` redi at gcc dot gnu.org
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=bug-59687-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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: linkBe 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).