public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "bkoz at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/11584] ios::iword() fails to zero-initialize storage on failure
Date: Mon, 26 Jan 2004 20:36:00 -0000 [thread overview]
Message-ID: <20040126203632.17681.qmail@sources.redhat.com> (raw)
In-Reply-To: <20030718231013.11584.sebor@roguewave.com>
------- Additional Comments From bkoz at redhat dot com 2004-01-26 20:36 -------
Subject: Re: ios::iword() fails to zero-initialize
storage on failure
>The only thing I really see wrong with the patch is that it zeros both
>the iword and pword failure storage, rather than the one being
>accessed. I'm going to post a modified patch as soon as I update the
>test case.
Ok.
>BTW, it doesn't seem to me to be a requirement that test case in this
>bug produce 0. The standard says that a failure to allocate space
>should return 0 storage, but it doesn't say how that space has to be
>allocated. Our implementation has a small amount of preallocated
>space, so accessing slot 1 doesn't fail. The problem that was raised
>is still generally valid, though.
Right. The issue, I think, is that the standard is under-specified.
What we should do, in the meantime, is try to come up with sensible
behavior. We have some test cases in this PR already, but what we should
do is document the new, "sensible" libstdc++ behavior in test cases.
Then, perhaps Martin could tell us if the sensible libstdc++ behavior,
as defined in these test cases, is sensible to him, as another library
vendor.
Once we have behavior that RW and libstdc++ agree is sensible, one of us
should submit a defect report.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11584
next prev parent reply other threads:[~2004-01-26 20:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-18 23:10 [Bug libstdc++/11584] New: " sebor at roguewave dot com
2003-07-29 16:56 ` [Bug libstdc++/11584] " ehrhardt at mathematik dot uni-ulm dot de
2003-08-23 0:52 ` dhazeghi at yahoo dot com
2003-09-10 14:46 ` bkoz at gcc dot gnu dot org
2003-09-17 23:50 ` bkoz at gcc dot gnu dot org
2003-09-18 12:35 ` Christian Ehrhardt
2003-09-18 12:49 ` ehrhardt at mathematik dot uni-ulm dot de
2003-12-30 20:42 ` jlquinn at optonline dot net
2004-01-08 17:21 ` bkoz at gcc dot gnu dot org
2004-01-26 1:45 ` jlquinn at gcc dot gnu dot org
2004-01-26 20:36 ` bkoz at redhat dot com [this message]
2004-01-27 2:32 ` jlquinn at gcc dot gnu dot org
2004-01-27 2:33 ` jlquinn at gcc dot gnu dot org
2004-01-27 4:50 ` bkoz at redhat dot com
2004-01-27 15:46 ` cvs-commit at gcc dot gnu dot org
2004-01-27 15:54 ` cvs-commit at gcc dot gnu dot org
2004-01-27 15:55 ` jlquinn at gcc dot gnu dot org
2004-01-27 16:00 ` pinskia at gcc dot gnu dot 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=20040126203632.17681.qmail@sources.redhat.com \
--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: 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).