From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8744 invoked by alias); 24 Feb 2006 20:40:51 -0000 Received: (qmail 8722 invoked by alias); 24 Feb 2006 20:40:48 -0000 Date: Fri, 24 Feb 2006 20:45:00 -0000 Message-ID: <20060224204048.8721.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "phil at mitre dot org" 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 X-SW-Source: 2006-02/txt/msg02865.txt.bz2 List-Id: ------- Comment #7 from phil at mitre dot org 2006-02-24 20:40 ------- Subject: RE: Passing a NULL char* into output stream now breaks the output stream Agreed, the stream object itself hopfully doesn't get corrupted (bad), but what I was refering to was "the data" itself, not the stream object. That is, in producing an output stream with a particular structure and cadence, it IS possible for it to become corrupted by violating the protocol of that output. In my recent example I was explaining how, even if I asserted ostream state and detected that an error had occurred, I would not be able to determine WHERE the error had occurred. So I could do cout.clear() and go on but, given my example, I wouldn't know which exact << operator failed when strung together. Therefore my output would be in a indeterminent state and I may well be better off if I'd just crashed and been forced to fix the problem. phil Phil Brown Lead Software Systems Engineer Mitre CAASD phil@mitre.org Perception is nine-tenths of the flaw. >-----Original Message----- >From: pcarlini at suse dot de [mailto:gcc-bugzilla@gcc.gnu.org] >Sent: Friday, February 24, 2006 2:57 PM >To: Brown, Phil >Subject: [Bug libstdc++/26458] Passing a NULL char* into >output stream now breaks the output stream > > > >------- Comment #6 from pcarlini at suse dot de 2006-02-24 >19:56 ------- >(In reply to comment #2) >> Otherwise, there's great potential that the output stream (the data) >> will become corrupted, even if you manage to check it state. > >By the way, there is no such thing as a "corrupted stream". >Either the state is >good, or it isn't. If, for some reason, you fear it isn't >better checking it. > > >-- > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458 > >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458