Paul Meyerholtz schrieb:
>=20
> I have found an inconsistent output by various compilers of the followi=
ng:
>=20
> char * p =3D 0;
> cout * q =3D "";

nobody seemed to complain about this line of code.  what the heck is
type 'cout'?  is this really the code you provided the compiler with?

regards

 robert

--=20
Robert Klemme
Software Engineer
-------------------------------------------------------------
myview technologies GmbH & Co. KG
Riemekestra=DFe 160 ~ D-33106 Paderborn ~ Germany
E-Mail: mailto:robert.klemme@myview.de
Telefon: +49/5251/69090-321 ~ Fax: +49/5251/69090-399
-------------------------------------------------------------

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <396DFE0F.E1F0D885@myview.de>,
Robert Klemme  <robert.klemme@myview.de> wrote:
>
>
>Paul Meyerholtz schrieb:
>>
>> I have found an inconsistent output by various compilers of the following:
>>
>> char * p = 0;
>> cout * q = "";
>
>nobody seemed to complain about this line of code.  what the heck is
>type 'cout'?  is this really the code you provided the compiler with?

It's obviously a type for:

   char * q = "";

If the other respondents noticed it, they didn't bother commenting on it
and just assumed the intended declaration.  It's certainly clear from the
context that this is what was intended.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Robert Klemme wrote:
>
> Paul Meyerholtz schrieb:
> >
> > I have found an inconsistent output by various compilers of the following:
> >
> > char * p = 0;
> > cout * q = "";
>
> nobody seemed to complain about this line of code.  what the heck is
> type 'cout'?  is this really the code you provided the compiler with?

In context, it seemed clear that it was a typo, and he meant to write
 char * q = "";
No doubt others made the same assumption.
---
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Sat, 8 Jul 2000 03:08:48 CST, Paul Meyerholtz
<pholtz@ix.netcom.com> wrote in comp.std.c++:

> I have found an inconsistent output by various compilers of the following:
>
> char * p = 0;

This initialization makes p a null pointer.  It does not point to
anything and dereferencing it is undefined behavior.

> cout * q = "";

This creates an unnamed array of one character, containing the
character value '\0', and points q at that character.  It is in a
legal memory location and represents a C string of zero length.

> cout << p << "\n\n";

Passing a pointer to char to cout causes it to dereference the pointer
to access all of the characters in sequence up to, and excluding, the
terminating '\0'.  Since p is a null pointer, dereferencing it
produces undefined behavior.

> cout << q;

This causes q to be dereferenced, resulting in the char '\0'.  Since
that is the terminating character, nothing is done.

>
> Most compilers seem to handle "cout << q" without a problem.  (But I
> have heard that Visual C++ 6 fails this test).

I seriously doubt that it does.  It should merely output nothing.

> However, the handling of "cout << p" seems to cause problems for most
> computers, with results from segment faults to garbage output.
> (CodeWarrior for the Mac, which I use, outputs a couple of garbage
> characters, but always the same ones).
>
> Why is the output of p and q different?

They are not the same thing.  p points to nothing, q points to a 0
length C string, which is a perfectly legal object.

> Is there anything in the standard about this?  Should cout check for the
> null pointer?

No, that's up to the programmer.  Passing a null pointer to any
function member or otherwise that is not specifically defined as
accepting a null pointer is a bug, and produces undefined behavior.

> Paul

Jack Klein
--
Home: http://jackklein.home.att.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz <pholtz@ix.netcom.com> wrote in message
news:39656D42.E049FCAA@ix.netcom.com...
> I have found an inconsistent output by various compilers of the following:
>
> char * p = 0;
> cout * q = "";
>
> cout << p << "\n\n";
> cout << q;
>
> Most compilers seem to handle "cout << q" without a problem.  (But I
> have heard that Visual C++ 6 fails this test).
>
> However, the handling of "cout << p" seems to cause problems for most
> computers, with results from segment faults to garbage output.
> (CodeWarrior for the Mac, which I use, outputs a couple of garbage
> characters, but always the same ones).
>
> Why is the output of p and q different?
>
> Is there anything in the standard about this?  Should cout check for the
> null pointer?
>

You've confused things (quite seriously too) - p is not the same as q

q is actually the string "\0" - ASCII (or whatever) 0 is placed at the end
of the string literal held in memory, and q will point to where that literal
is stored (almost certainly a non-zero address)

p, however, is a pointer to memory address 0.  When
ostream::operator<<( char * ) tries to output p, it dereferences the
pointer, which it thinks is a character array starting at memory location
0 - out of range on most machines, and hence crashes.  It works on the mac
because mac memory protection is pretty poor really compared to windows or
unix.

As for MSVC++6, I shoved this through it, and it worked as expected:

----

#include <iostream>

int main( void )
{
    char * p = "";

    std::cout << p << std::endl;

    return 0;
}

----

Ian Darling




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39656D42.E049FCAA@ix.netcom.com>,
Paul Meyerholtz  <pholtz@ix.netcom.com> wrote:

>char * p = 0;

>cout << p << "\n\n";

>However, the handling of "cout << p" seems to cause problems for most
>computers, with results from segment faults to garbage output.

Dereferencing a NULL pointer is undefined, which means the code
could handle it gracefully, kill the program, crash the computer,
reformat the hard disk, or make daemons fly out your nose.....

>Is there anything in the standard about this?  Should cout check for the
>null pointer?

It would be nice if ostream &operator<<(const char*) did something
sensible (like print "null"), but isn't required.
--
--
<a href="http://www.poohsticks.org/drew/">Home Page</a>
For those who do, no explanation is necessary.
For those who don't, no explanation is possible.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz <pholtz@ix.netcom.com> writes:

|>  I have found an inconsistent output by various compilers of the
|>  following:

|>  char * p =3D 0;
|>  cout * q =3D "";

|>  cout << p << "\n\n";
|>  cout << q;

|>  Most compilers seem to handle "cout << q" without a problem.  (But I
|>  have heard that Visual C++ 6 fails this test).

I'd be surprised.  I don't think any compiler would have a problem with
cout << q.

|>  However, the handling of "cout << p" seems to cause problems for
|>  most computers, with results from segment faults to garbage output.

Outputting a char* involves derefencing it.  Dereferening a null pointer
is undefined behavior.  Consider yourself lucky that it didn't reformat
your disk.

|>  Why is the output of p and q different?

Because the input is different.  Why should it be the same?  Why should
outputting a null pointer have any defined behavior?

|>  Is there anything in the standard about this?

That a program which attempts to output a null char* has undefined
behavior.  It is a programming error.

|>  Should cout check for the null pointer?

Why?  It could possibly check for a null pointer, but then, what about
all of the other illegal values?

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz wrote:
>
> I have found an inconsistent output by various compilers of the following:
>
> char * p = 0;
> cout * q = "";
>
> cout << p << "\n\n";
> cout << q;
>
> Most compilers seem to handle "cout << q" without a problem.  (But I
> have heard that Visual C++ 6 fails this test).

I don't think VC++ failes the test.  It's pretty basic stuff.  It certainly
works fine in VC++ 5.
>
> However, the handling of "cout << p" seems to cause problems for most
> computers, with results from segment faults to garbage output.

Not surprising, you are invoking undefined behavior.

> Why is the output of p and q different?

There is a whole lot of difference between a null pointer constant (0)
and an empty string literal.  One is a guaranteed invalid pointer, the
other is a pointer to a statically allocated array of one character with
a zero in it.

>
> Is there anything in the standard about this?  Should cout check for the
> null pointer?

No, the programmer should avoid giving null pointers to things that are expecting
valid poitners.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

in article B58BAAC8.6E61%anders@milkweed.com, Anders Pytte at
anders@milkweed.com wrote on 7/8/00 7:49 AM:

> in article 39656D42.E049FCAA@ix.netcom.com, Paul Meyerholtz at
> pholtz@ix.netcom.com wrote on 7/8/00 5:08 AM:
>
>> I have found an inconsistent output by various compilers of the following:
>>
>> char * p = 0;
>> cout * q = "";
>>
>> cout << p << "\n\n";
>> cout << q;
>>

[snip]

> In the above, "cout << p" says, print the c string stored at address 0,
> while "cout << q" says, print a c string of zero length. Why should these
> produce the same output?

This was a bit sloppy of me considering the heated discussion of NULL next
door. It would be more correct to say simply that dereference of a NULL
pointer is undefined, although on a typical implementation it amounts to
accessing data stored at location 0. This is probably what happened when
Paul used Metrowerks C++ on the Mac.

Anders.

--
Anders Pytte                                   Milkweed Software
PO Box 32                                  voice: (802) 586-2545
Craftsbury, VT 05826                  email: anders@milkweed.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I have found an inconsistent output by various compilers of the following:

char * p = 0;
cout * q = "";

cout << p << "\n\n";
cout << q;

Most compilers seem to handle "cout << q" without a problem.  (But I
have heard that Visual C++ 6 fails this test).

However, the handling of "cout << p" seems to cause problems for most
computers, with results from segment faults to garbage output.
(CodeWarrior for the Mac, which I use, outputs a couple of garbage
characters, but always the same ones).

Why is the output of p and q different?

Is there anything in the standard about this?  Should cout check for the
null pointer?

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

in article 39656D42.E049FCAA@ix.netcom.com, Paul Meyerholtz at
pholtz@ix.netcom.com wrote on 7/8/00 5:08 AM:

> I have found an inconsistent output by various compilers of the following:
>
> char * p = 0;
> cout * q = "";
>
> cout << p << "\n\n";
> cout << q;
>
> Most compilers seem to handle "cout << q" without a problem.  (But I
> have heard that Visual C++ 6 fails this test).
>
> However, the handling of "cout << p" seems to cause problems for most
> computers, with results from segment faults to garbage output.
> (CodeWarrior for the Mac, which I use, outputs a couple of garbage
> characters, but always the same ones).
>
> Why is the output of p and q different?

In the above, "cout << p" says, print the c string stored at address 0,
while "cout << q" says, print a c string of zero length. Why should these
produce the same output?

> Is there anything in the standard about this?  Should cout check for the
> null pointer?

Perhaps, but that is not how it is defined. Actually, I'm not aware of any
standard functions that take char* as an input and that check for null. This
appears to be the responsibility of the caller :-)

Anders.

--
Anders Pytte                                   Milkweed Software
PO Box 32                                  voice: (802) 586-2545
Craftsbury, VT 05826                  email: anders@milkweed.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]