[Bug c++/26458] New: Passing a NULL char* into output stream now breaks the output stream

[Bug c++/26458] New: Passing a NULL char* into output stream now breaks the output stream

[phil at mitre dot org]

Prior behavior handled passing a char* with a NULL value into an output stream;
the result was that nothing printed.  As of versions 3 and later this behavior
has changed.  Perhaps a bug, perhaps a new enforcement.

The result is that the output stream no longer writes anything (to file or
stdout) until the descriptor is closed, and then only the unflushed text up
until the NULL was passed.

Example code:

#include <iostream>
main() {
  char *str = NULL;
  cout << "Hello " << str << " there" << endl;
  cout << "still dead?" << endl;
}

Resulting output is:

Hello_

No further output is sent.  Perhaps, if it is deemed improper to allow a NULL
in a known type being passed to a stream, then a SEG fault might be better than
continue with no indication, except for lack of output.


-- 
           Summary: Passing a NULL char* into output stream now breaks the
                    output stream
           Product: gcc
           Version: 3.2.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: phil at mitre dot org
 GCC build triplet: 2.3.2 20030502 (RedHat linux 2.3.2-53)
  GCC host triplet: RedHat linux 2.4.21-37 enterprise


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[pcarlini at suse dot de]

------- Comment #1 from pcarlini at suse dot de  2006-02-24 16:53 -------
The change is certainly intended and the important point is that is not true
that there is no indication of the failure, quite to the contrary the badbit is
set. Try changing your test like this:

  char *str = NULL;
  cout << "Hello " << str;

  assert( !cout.good() );
  cout.clear();

  cout << " there" << endl;

  assert( cout.good() );

  cout << "still dead?" << endl;

  assert( cout.good() );


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
          Component|c++                         |libstdc++
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[phil at mitre dot org]

------- Comment #2 from phil at mitre dot org  2006-02-24 18:45 -------
Subject: RE:  Passing a NULL char* into output stream now breaks the output
stream

Thanks for the quick response.  This came up when some old systems were
ported from Solaris using gcc-2.9.5 or so and out output files just
stopped growing.  Took a couple days of detailed debugging to track it
down to a low-level string class...

In any event, my experience is that developers tend not to assert the
status of the stream operators every time they use them, especially
output streams.  In general, with almost any output descriptor or
stream, you use it correctly or not to your peril, subject to core
dumps and the like.  However, this behavior seems to expect that all
developers will do the right thing and always check stream state after
each << use (never mind if you string several together).  But the
reason they got into this state to begin with is because they did
something wrong, sending NULL where they shouldn't, so how can you
expect, if they did that, that they would bother to check the ostream
operator.

So my feeling is that the effect of doing this should be one of the
following:

1. allow << for NULL of known type by doing nothing; if (NULL)
return...
2. seg fault for making an ostream deref a NULL 

Otherwise, there's great potential that the output stream (the data)
will become corrupted, even if you manage to check it state.  For
example:

cout << "hello " << val1 << " is " << val2 << " here today?" << endl;
assert(!cout.good());

It's almost impossible to determine, even if you know the state is bad,
how much data was successfully sent into the stream before it crapped
out.  On one level you're doing a nice thing by not crashing the
program, but on another it seems unlikely you'll be able to recover the
stream, by perhaps filling in missing pieces correctly, so you might as
well crash.

        Thanks again for the response...

                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 11:53 AM
>To: Brown, Phil
>Subject: [Bug libstdc++/26458] Passing a NULL char* into 
>output stream now breaks the output stream
>
>
>
>------- Comment #1 from pcarlini at suse dot de  2006-02-24 
>16:53 -------
>The change is certainly intended and the important point is 
>that is not true
>that there is no indication of the failure, quite to the 
>contrary the badbit is
>set. Try changing your test like this:
>
>  char *str = NULL;
>  cout << "Hello " << str;
>
>  assert( !cout.good() );
>  cout.clear();
>
>  cout << " there" << endl;
>
>  assert( cout.good() );
>
>  cout << "still dead?" << endl;
>
>  assert( cout.good() );
>
>
>-- 
>
>pcarlini at suse dot de changed:
>
>           What    |Removed                     |Added
>---------------------------------------------------------------
>-------------
>             Status|UNCONFIRMED                 |RESOLVED
>          Component|c++                         |libstdc++
>         Resolution|                            |INVALID
>
>
>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

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[phil at mitre dot org]

------- Comment #3 from phil at mitre dot org  2006-02-24 18:54 -------
See comment #2.


-- 

phil at mitre dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-02-24 18:55 -------
I think Paolo forgot to mention this is required by the C++ standard.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[phil at mitre dot org]

------- Comment #5 from phil at mitre dot org  2006-02-24 19:00 -------
(In reply to comment #4)
> I think Paolo forgot to mention this is required by the C++ standard.

Well that's different then.  I realize that many non-standard things were
allowed pre gcc-3.0 and that 3+ was starting to enforce more but I wasn't aware
of this particular item being spec'd in the standard.

So where do I submit a PR for the standard?!?  :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[pcarlini at suse dot de]

------- 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

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[phil at mitre dot org]

------- 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

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[pcarlini at suse dot de]

------- Comment #8 from pcarlini at suse dot de  2006-02-24 21:03 -------
(In reply to comment #7)
> .                                          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.

Indeed, I understand, but this is a general "issue", which has nothing to do
with the specific inserter. Any time you "batch" many insertions you loose the
ability to do fine grained error checking, by definition.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[phil at mitre dot org]

------- Comment #9 from phil at mitre dot org  2006-02-24 21:14 -------
Subject: RE:  Passing a NULL char* into output stream now breaks the output
stream

Yup.  But by providing the ability to batch stream inserts, per the
standard I presume otherwise it's not much of a stream, then you create
the situation where this difficulty exists.  That's kinda why I joked
about "filing a PR with the standard".  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.

BTW, I thought that GNU was never one to limit themselves to a standard
when they could always rise above it and do better.

                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 4:03 PM
>To: Brown, Phil
>Subject: [Bug libstdc++/26458] Passing a NULL char* into 
>output stream now breaks the output stream
>
>
>
>------- Comment #8 from pcarlini at suse dot de  2006-02-24 
>21:03 -------
>(In reply to comment #7)
>> .                                          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.
>
>Indeed, I understand, but this is a general "issue", which has 
>nothing to do
>with the specific inserter. Any time you "batch" many 
>insertions you loose the
>ability to do fine grained error checking, by definition.
>
>
>-- 
>
>
>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

[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[pcarlini at suse dot de]

------- 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