From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17708 invoked by alias); 26 Jan 2004 20:36:34 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17682 invoked by alias); 26 Jan 2004 20:36:32 -0000 Date: Mon, 26 Jan 2004 20:36:00 -0000 Message-ID: <20040126203632.17681.qmail@sources.redhat.com> From: "bkoz at redhat dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20030718231013.11584.sebor@roguewave.com> References: <20030718231013.11584.sebor@roguewave.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/11584] ios::iword() fails to zero-initialize storage on failure X-Bugzilla-Reason: CC X-SW-Source: 2004-01/txt/msg03319.txt.bz2 List-Id: ------- 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