From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20190 invoked by alias); 24 Feb 2006 21:22:16 -0000 Received: (qmail 20173 invoked by uid 48); 24 Feb 2006 21:22:12 -0000 Date: Fri, 24 Feb 2006 21:32:00 -0000 Message-ID: <20060224212212.20172.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: "pcarlini at suse dot de" 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/msg02879.txt.bz2 List-Id: ------- Comment #10 from pcarlini at suse dot de 2006-02-24 21:22 ------- (In reply to comment #9) > ....................... If the standard says you can > string together inserts, and that a failed insert will "disable" the > stream until the error is cleared, but not allowing you to determine > where an error occurred seems a failing of the standard. I don't, because I cannot see other options, besides a very hard fail, which means application termination. In general, one don't want that. Again, the issue is very, very general, has nothing to do with NULLs. Any time an insertion can fail for some reason (i.e., your hard disk breaks ;) you want fine grained error checking. > BTW, I thought that GNU was never one to limit themselves to a standard > when they could always rise above it and do better. This is simply not true. The standard is tracked very closely, as close as possible. We spend a lot of time on that, because also means participating to the ongoing discussions on the ISO mailing lists. If we really believe something can be done better we try to change the standard itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458