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] The description of ios::noreplace is hilarious Date: Sat, 11 Jan 2014 12:30:00 -0000 [thread overview] Message-ID: <bug-59687-4-YKRHLQkEGC@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-59687-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59687 Christopher Yeleighton <giecrilj at stegny dot 2a.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|FIXED |--- --- Comment #4 from Christopher Yeleighton <giecrilj at stegny dot 2a.pl> --- (In reply to Jonathan Wakely from comment #2) > Author: redi > Date: Fri Jan 10 14:30:27 2014 > New Revision: 206525 > trunk/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml You: Because iostream modes correspond to <function>fopen(3)</function> modes these flags are not supported. Me: The implication is 1⇒1, so this is formally valid. But correlation is not causation; in this case, you have (fopen (path, "wx")) both implemented in GNU and standardised. So your statement is misleading, at least for (noreplace). You: If you need to check for existence and open a file as a single operation then you will need to use OS-specific facilities outside the C++ standard library, such as <function>open(2)</function> Me: Maybe it would be worth mentioning how you can construct a stream from a file descriptor so as to avoid a resource leak (the constructor must not throw for this scheme to work). It seems (noreplace) is more important in practice than (nocreate). Now that it is standardised, could you consider providing (__noreplace) instead? See also <URL: https://groups.google.com/a/isocpp.org/d/msg/std-proposals/I5z9QIo7KHU/D3eC_NRlMjMJ > Meta: I admit the bug is sort-of fixed but still I tentatively reopen to see if you would reconsider the text given the remarks above. Please forgive me if it is too much disruption for you. >From gcc-bugs-return-440087-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jan 11 12:55:40 2014 Return-Path: <gcc-bugs-return-440087-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 28959 invoked by alias); 11 Jan 2014 12:55:40 -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 28940 invoked by uid 48); 11 Jan 2014 12:55:36 -0000 From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/59687] The description of ios::noreplace is hilarious Date: Sat, 11 Jan 2014 12:55: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: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: <bug-59687-4-ycaOUGLCH4@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/msg01229.txt.bz2 Content-length: 669 http://gcc.gnu.org/bugzilla/show_bug.cgi?idY687 Jonathan Wakely <redi at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> --- I'm not spending any more time on documentation for features that we don't support, and that most compilers have not supported since last century. That chapter of the libstdc++ manual is not the place for people to learn how to write correct programs.
next prev parent reply other threads:[~2014-01-11 12:30 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-01-05 19:45 [Bug libstdc++/59687] New: " giecrilj at stegny dot 2a.pl 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 [this message] 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-YKRHLQkEGC@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).