Uninitialized values?

[howa]

Hello,

What are the default value for initialized variable?

e.g.

int d; // debug give me -858993460
char c; // debug give me -52


I am using VS.net 2005


Thanks.

 

[Bo Persson]

Hello,

What are the default value for initialized variable?

e.g.

int d; // debug give me -858993460
char c; // debug give me -52


I am using VS.net 2005


Thanks.

There is no default value, just the random bits that happen to be in
that memory location.

If you want a non-random value, just ask for it:

int d = 0;
char c = 'a';


Bo Persson

 

[red floyd]

Hello,

What are the default value for initialized variable?

e.g.

int d; // debug give me -858993460
char c; // debug give me -52


I am using VS.net 2005

It's either unspecified or implementation defined.

However, in the case of VS, it's all cc's.

 

[red floyd]

Hello,

What are the default value for initialized variable?

e.g.

int d; // debug give me -858993460
char c; // debug give me -52


I am using VS.net 2005

Now that I think of it, the value is undefined, and accessing an
undefined variable is undefined behavior.

 

[Christian Hackl]

red floyd write:

Now that I think of it, the value is undefined, and accessing an
undefined variable is undefined behavior.

You mean the following is actually UB, meaning that a conforming
implementation may e.g. crash the program or format your hard disk?

#include <iostream>
int main()
{
int x;
std::cout << x;
}

I thought the value was more or less random and that's it. Could you
clarify what the standard really has to say about it?

 

[James Kanze]

red floyd write:

You mean the following is actually UB, meaning that a
conforming implementation may e.g. crash the program or format
your hard disk?

#include <iostream>
int main()
{
int x;
std::cout << x;
}

I thought the value was more or less random and that's it.
Could you clarify what the standard really has to say about
it?

It's undefined behavior for all types except unsigned char. All
other types can have trap representations.

 

[Jim Langston]

It's undefined behavior for all types except unsigned char. All
other types can have trap representations.

Representations. It's not undefined behavior, just an undefined value.

 

[Kai-Uwe Bux]

Representations. It's not undefined behavior, just an undefined value.

A trap representation is a bit-pattern that does not correspond to a valid
value of the type of the object. Undefined behavior happens when such a
bit-pattern is present at &x when x is handed to std::cout.


Best

Kai-Uwe Bux

 

[di]

red floyd dixit:

Now that I think of it, the value is undefined, and accessing an
undefined variable is undefined behavior.

except if they are global, in which case they are initialized to 0.

int i; // <== garanty to be 0

int main() {}

 

[howa]

Hi all,

Just find some interesting stuffs...on VS.net 2005

#include <iostream>

using namespace std;

int main() {

int j;
cout<<j;

system("pause");
return 0;
}


The above program always return "1"

Now try...

#include <iostream>

using namespace std;

int main() {

int a, j;
cout<<j;

system("pause");
return 0;
}


It always return "4428403"

I am running in debug mode of VS.net

Any idea?

Howard

 

[Ian Collins]

[please don't top-post]

Hi all,

Just find some interesting stuffs...on VS.net 2005

#include <iostream>

using namespace std;

int main() {

int a, j;
cout<<j;

system("pause");
return 0;
}


It always return "4428403"

I am running in debug mode of VS.net

Any idea?

Luck.

 

[Christian Hackl]

A trap representation is a bit-pattern that does not correspond to a valid
value of the type of the object. Undefined behavior happens when such a
bit-pattern is present at &x when x is handed to std::cout.

Thank you. Looks like I had no idea how evil it _really_ is to use
uninitialised variables!

 

[James Kanze]

Representations. It's not undefined behavior, just an
undefined value.

A trap representation means that the program "traps" whenever
that representation is read from memory. What happens when the
program traps is undefined behavior according to the
standard---in most modern hosted environments, it will cause a
core dump or its equivalent.

 

[James Kanze]

The word the standard uses is INDETERMINATE.

For the contents of d and c. The word the standard uses for
"reading" the indeterminate contents of d is "undefined
behavior".

It's a gross piece of insanity left over from historical
C stupidity that certain types neglect to perform their
default initialization at times (the default initialization
of int and char is to zero initialize them by the way).

Well, I can't disagree with that.

 

[Default User]

Hi all,

Just find some interesting stuffs...on VS.net 2005

#include <iostream>

using namespace std;

int main() {

int j;
cout<<j;

system("pause");
return 0;
}


The above program always return "1"

Now try...

#include <iostream>

using namespace std;

int main() {

int a, j;
cout<<j;

system("pause");
return 0;
}


It always return "4428403"

I am running in debug mode of VS.net

Any idea?

There is no defined behavior for Undefined Behavior. Learn that. Live
that.




Brian

 

[Stefan Ram]

Undefined Behavior

»if no initializer is specified for a non-static object,
the object and its subobjects, if any, have an
indeterminate initial value« - ISO/IEC 14882:2003(E), 8.5p9

Will writing an indeterminate value cause undefined behavior?

 

[Kai-Uwe Bux]

»if no initializer is specified for a non-static object,
the object and its subobjects, if any, have an
indeterminate initial value« - ISO/IEC 14882:2003(E), 8.5p9

Will writing an indeterminate value cause undefined behavior?

Unless the type is unsigned char, the object might have a bit-pattern that
does not correspond to a legal value (trap representation). If the
indeterminate value happens to be invalid, reading it can cause anything.
Therefore, reading an indeterminate value of type int is undefined
behavior.


Best

Kai-Uwe Bux

 

[Stefan Ram]

Unless the type is unsigned char, the object might have a
bit-pattern that does not correspond to a legal value (trap
representation).

I can't find the word »trap« in ISO/IEC 14882:2003(E),
but I know it from ISO/IEC 9899:1999 (E). Maybe the authors
of ISO/IEC 14882:2003(E) thought that this was self-evident
or only use »illegal value« - but I also can not find
»illegal value« or »legal vallue« in ISO/IEC 14882:2003(E).

You might be right, but I can not prove it from ISO/IEC
14882:2003(E). May ISO/IEC 14882:2003(E) targets a smaller set
of architectures than ISO/IEC 9899:1999 (E), where there are
no trap representations? A C++ compiler will not be able to
hide trap representation from the programmer if a C compiler
can't hide them.

I also found this suggestion from November 3, 1995, which does
/not/ seem to be implemented in ISO/IEC 14882:2003(E):

»476 - Can objects with "indeterminate initial value" be referred to?

8.5p6 says:
"If no initializer is specified for an object with automatic or
dynamic storage duration, the object and its subobjects, if any,
have an indeterminate initial value."

The C standard specifies that accessing a variable with
indeterminate value results in undefined behavior, but the C++ draft
contains no such language.

Proposed Resolution:
Add the following text at the end of 8.5 paragraph 6:
"Referring to an object with an indeterminate value results in
undefined behavior."«

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0803.htm

 

[Stefan Ram]

I can't find the word »trap« in ISO/IEC 14882:2003(E),
but I know it from ISO/IEC 9899:1999 (E).

ISO/IEC 14882:2003(E) also contains

»C++ is a general purpose programming language based on
the C programming language as described in ISO/IEC
9899:1990 Programming languages - C (1.2).«

But then, ISO/IEC 14882:2003(E) specifies fundamental scalar
types in detail and does not just refer to ISO/IEC 9899:1990.
So, it is not obvious whether one can just assume that
arbitrary assertions in this regard (about trap
representations) can be regarded to be implicitly included
from ISO/IEC 9899:1990.

 

[Ian Collins]

Jack Klein wrote:


I commonly write code of this form:

std::vector< std::string> >::const_iterator someItemIWantToProcess;

That'll be a syntax error.

for (someItemIWantToProcess = collection.begin(); someItemIWantToProcess
!= collection.end(); ++someItemIWantToProcess)
{
....
}

Where the iterator is defined outside the for loop, *solely because it
would make the line too big and clumsy*.

Ever thought of breaking the line down into its parts?

Long templated types are best tidied up using typedefs.

I don't want automatic
initialisation; I'd be quite happy if the debug-mode runtime checked
for uninitialised use.

It doesn't have to, that's a job for a static checking tool like lint,
or even the compiler.