[Bug c++/60959] New: Does “cout<<(char*)NULL” doing “close(1)” ?

[Bug c++/60959] New: Does “cout<<(char*)NULL” doing “close(1)” ?

[sree.gooogle at gmail dot com]

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

            Bug ID: 60959
           Summary: Does “cout<<(char*)NULL” doing “close(1)” ?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sree.gooogle at gmail dot com

In the following piece of C++ code I have used cout<<(char*)NULL; after this
line, my program printing nothing to the output screen. Does it mean I have
done close(1) with cout here?

#include<iostream>
using namespace std;

void f(){
    cout<<"\nfun\n";
}

main(){
cout<<(char*)NULL;
f(); //not getting printed !
cout<<"\nhello\n";  //not getting printed !
cout<<"hii how are you?"; //not getting printed, why??
}

compiled using:
g++ myprog.cpp
run:
./a.out

o/p:
 Prints nothing

I have tried this code in gcc as well as DevCpp compiler, same behavior
observed. Is this a compiler bug? Please provide detailed information about
this behavior. 

Thank you!
>From gcc-bugs-return-449838-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 25 02:51:27 2014
Return-Path: <gcc-bugs-return-449838-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31660 invoked by alias); 25 Apr 2014 02:51:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31627 invoked by uid 48); 25 Apr 2014 02:51:22 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60959]=?UTF-8?Q? Does “cout?=<<(char*)=?UTF-8?Q?NULL” doing “close?=(1)=?UTF-8?Q?” ?=?
Date: Fri, 25 Apr 2014 02:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-60959-4-zR7eUVXskC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60959-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60959-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg01858.txt.bz2
Content-length: 555

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`959

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
No it sets the badbit on the stream which causes nothing to be printed after
that.

      if (!__s)
 __out.setstate(ios_base::badbit);

[Bug c++/60959] Does “cout<<(char*)NULL” doing “close(1)” ?

[sree.gooogle at gmail dot com]

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

--- Comment #2 from Sreenath U S <sree.gooogle at gmail dot com> ---
"sets the badbit on the stream which causes nothing to be printed after that.";
So this is a defined behavior or it varies on compiler to compiler?

[Bug c++/60959] Does “cout<<(char*)NULL” doing “close(1)” ?

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Sreenath U S from comment #2)
> "sets the badbit on the stream which causes nothing to be printed after
> that."; So this is a defined behavior or it varies on compiler to compiler?

I think it is undefined behavior, GCC decides to play it safe.

[Bug c++/60959] Does “cout<<(char*)NULL” doing “close(1)” ?

[sree.gooogle at gmail dot com]

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

--- Comment #4 from Sreenath U S <sree.gooogle at gmail dot com> ---
Okay Thanks. One more thing, Is there any way to make the remaining cout
statements to get printed in gcc without removing the faulty
cout<<(char*)NULL;?

[Bug c++/60959] Does “cout<<(char*)NULL” doing “close(1)” ?

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Andrew is correct, the standard says:

   Requires: s shall not be a null pointer.

So your program has undefined behaviour and should be fixed.

You can clear the badbit with cout.clear()