This is undefined, but is it legal?

[jl_post]

Hi,

I've heard that if you've declared a variable (such as a double or
an int) and not initialize it, then the result of printing out its
value is undefined.

I've also heard that "undefined behavior" can mean just about
anything, such as "flying monkeys shooting out of your nose." Sure,
that's an exaggeration, but normally I interpret that to mean that the
program can crash (or cease running) erratically, or even corrupt
data.

So my question is: Although I can never safely predict the printed
output of an uninitialized int or double, is it still safe (or legal)
to do so? In other words, if I run this program:

#include <iostream>

int main(int argc, char ** argv)
{
int i;
double d;

std::cout << "i = " << i << std::endl; // safe?
std::cout << "d = " << d << std::endl; // safe?

return 0;
}

I may not be able to predict what will print out, but is there any
chance that the program can crash because of those lines?

If you're curious why I ask this, it's because in some code I'm
working through there is a structure with ints -- some of which are
never used nor initialized. However, this structure (will all its
ints) is getting written out to disk (and later read back in). But at
no time are the values of these uninitialized ints used for logic in
the code.

Because the code is writing out uninitialized values (and later
reading them in), is there a possibility that the program can self-
destruct (or corrupt anything) just because those ints weren't
initialized?

Thanks in advance.

-- Jean-Luc

[=?ISO-8859-1?Q?Marcel_M=FCller?=]

James Kanze schrieb:

The actual language says that it is using the value of an
uninitialised object which has undefined behavior. Roughly
speaking (or perhaps exactly speaking), it is the lvalue to
rvalue conversion which triggers the undefined behavior. (You
can still assign to the object, for example.)

Hmm, plausible definition.

>Strictly speaking this applies to PODs only.

What makes you say that? It applies to everything. (Of course,
a lot of non-POD's have user defined constructors, which take
care of the initialization. But the standard doesn't require
it.)

And that is the point. The standard cannot ensure that a user defined
class constructor initializes all members. E.g. if a pointer member is
not initialized correctly, the assignment operator may fail to cleanup
the old content. On the other side there might be good reasons not to
initialize all PODs of a class in the constructor. So it is always up to
the user to ensure the defined behavior. I would not call it a good
design, when invoking the assignment operator for a default constructed
object is undefined behavior. But the standard does not generally
require defined behavior in this case. In some GUI libraries it is e.g.
required to call some initialization function after the constructor is
called, because some abstract base classes cannot be fully initialized
without the virtual functions of the derived class. Before that
initialization call nearly any other function call is invalid.

>libraries only. E.g. some std::vector implementations do not
initialize the elements in the range [size(),capacity ()[.

Some? The standard doesn't allow them to initialize those
elements (and it doesn't allow you to access them).

Oh, I always thought that this is some kind of optimization, since
objects in an vector have to be default constructable anyway.
Marcel

[Pete Becker]

On 2008-07-27 07:09:48 -0400, Nick Keighley
<ni************ ******@hotmail. comsaid:

On Jul 26, 4:30Â*pm, Pete Becker <p...@versatile coding.comwrote :

>On 2008-07-26 10:31:04 -0400, "Andrew Koenig" <[e-mail] id:

>>"Lionel B" <m...@privacy.n etwrote in message
news:g6****** ****@south.jnrs .ja.net...

>>>You're ok. The *value* of the variable i may well be undefined, but
i is nonetheless an int; and outputting an int - any int, whatever its
value - should never crash your program. Ditto double, etc.

>>Not true. Â*It's not true in theory for int, and definitely not true i

n

>>practice for double -- because IEEE floating-point, which most modern
computers use, has a notion of "signaling not-a-number" values that cau

se a

>>run-time error condition if accessed.

My reading of IEEE-754 is that acessing a signaling NaN causes an
invalid operation exception by default, and the result of that
exception is just to return a quite NaN. Unless the program has
installed a trap handler, this is completely innocuous.

http://blogs.msdn.com/oldnewthing/ar...3/8682463.aspx

seems to disagree. Or at least trap handlers seem to get enabled
more easily than you'd think on some OSs

It says that code that your program calls, even if you didn't write it,
can set up trap handlers. That's completely consistent with what I said.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

On Jul 27, 1:17 pm, Marcel Müller <news.5.ma...@s pamgourmet.com>
wrote:

James Kanze schrieb:

libraries only. E.g. some std::vector implementations do not
initialize the elements in the range [size(),capacity ()[.

Some? The standard doesn't allow them to initialize those
elements (and it doesn't allow you to access them).

Oh, I always thought that this is some kind of optimization,
since objects in an vector have to be default constructable
anyway.

Since when? All the standard requires is copy constructable and
assignable. (Which is a good thing, because I have some
instances of vectors of objects which are not default
constructable.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Old Wolf]

On Jul 26, 9:08 am, James Kanze <james.ka...@gm ail.comwrote:

On Jul 25, 6:04 pm, jl_p...@hotmail .com wrote:

I've heard that if you've declared a variable (such as a
double or an int) and not initialize it, then the result of
printing out its value is undefined.

Anything you do with its *value* is undefined behavior. (You
can still take its address, or assign to it.) With the
exception of unsigned char and char.

And how are you writing them out? If you're just copying the
bits of a struct to disk, then you have no guarantee of being
able to read the data in the future.

Nobody's mentioned this explicitly yet :
AFAIK, it is not undefined to copy the bits
to disk and read them back, even if the variable
is uninitialized. (Of course the value is
still indeterminate after the garbage is read
back from disk).

[James Kanze]

On Jul 27, 11:42 pm, Old Wolf <oldw...@inspir e.net.nzwrote:

On Jul 26, 9:08 am, James Kanze <james.ka...@gm ail.comwrote:

On Jul 25, 6:04 pm, jl_p...@hotmail .com wrote:

I've heard that if you've declared a variable (such as a
double or an int) and not initialize it, then the result of
printing out its value is undefined.

Anything you do with its *value* is undefined behavior. (You
can still take its address, or assign to it.) With the
exception of unsigned char and char.

And how are you writing them out? If you're just copying the
bits of a struct to disk, then you have no guarantee of being
able to read the data in the future.

Nobody's mentioned this explicitly yet :
AFAIK, it is not undefined to copy the bits
to disk and read them back, even if the variable
is uninitialized. (Of course the value is
still indeterminate after the garbage is read
back from disk).

That's a good point. I think it depends on how you do it, but
in most cases, it should be OK. All the C++ standard speaks
about directly is istream::read and ostream::write (and the
streambuf functions they used); for istream, ostream and
streambuf, the interface uses char*, so you're OK. For
wistream, wostream and wstreambuf? A wchar_t can have a
trapping representation. As for fread and fwrite, inherited
from C, they are required to do input and output "as if" using
fgetc and fputc, which means byte access as well (even if they
take a void*), and thus defined behavior.

For anything else, it depends on the implementation, but in
practice, it's hard to imagine a system level read or write
doing anything but byte accesses.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]