Velocity Reviews > Value of uninitialized variable

# Value of uninitialized variable

Philipp Klaus Krause
Guest
Posts: n/a

 01-19-2010
What's the value of an uninitialized variable?

E.g. for a bool, is it always true or false? For an int is it an integer
value in [INT_MIN, INT_MAX]?

Philipp

Kenny McCormack
Guest
Posts: n/a

 01-19-2010
In article <4b5591e6\$0\$9752\$(E-Mail Removed)>,
Philipp Klaus Krause <(E-Mail Removed)> wrote:
>What's the value of an uninitialized variable?

Not much. Maybe 50 cents on the open market.

Nick Keighley
Guest
Posts: n/a

 01-19-2010
On 19 Jan, 11:05, Philipp Klaus Krause <(E-Mail Removed)> wrote:

> What's the value of an uninitialized variable?

assuming you're talking about automatic variables (see Richard's post)
then the value is undefined. The standard allows "trap values" and
attempts to read a trap value will cause the program to fail.

> E.g. for a bool, is it always true or false?

no.

> For an int is it an integer value in [INT_MIN, INT_MAX]?

no

but if it makes you any happier unsigned char is an exception in that
it cannot be a trap value. I'm guessing that all bit patterns are
hence valid values.

Ersek, Laszlo
Guest
Posts: n/a

 01-19-2010
In article <(E-Mail Removed)>, Nick Keighley <(E-Mail Removed)> writes:
> On 19 Jan, 11:05, Philipp Klaus Krause <(E-Mail Removed)> wrote:
>
>> What's the value of an uninitialized variable?

>
> assuming you're talking about automatic variables (see Richard's post)
> then the value is undefined. The standard allows "trap values" and
> attempts to read a trap value will cause the program to fail.

The derivation seems to be:

C99 6.7.8 Initialization, p10: "If an object that has automatic storage
duration is not initialized explicitly, its value is indeterminate."

C99 3.17.2 "indeterminate value: either an unspecified value or a trap
representation"

C99 6.2.6 Representations of types / 6.2.6.1 General, p5

"Certain object representations need not represent a value of the object
type. If the stored value of an object has such a representation and is
read by an lvalue expression that does not have character type, the
behavior is undefined. If such a representation is produced by a side
effect that modifies all or any part of the object by an lvalue
expression that does not have character type, the behavior is undefined.
41) Such a representation is called a trap representation."

Footnote 41:

"Thus, an automatic variable can be initialized to a trap representation
without causing undefined behavior, but the value of the variable cannot
be used until a proper value is stored in it."

For C90, the path is a bit different:

C90 6.5.7 Initialization

"If an object that has automatic storage duration is not initialized
explicitly, its value is indetelminate."

C90 3.16 "undefined behavior: Behavior, upon use of [...] indeterminately
valued objects, for which this International Standard imposes no
requirements."

I'm not sure if in C90 an access with character type is exempted like in
C99.

Cheers,
lacos

Seebs
Guest
Posts: n/a

 01-19-2010
On 2010-01-19, Philipp Klaus Krause <(E-Mail Removed)> wrote:
> What's the value of an uninitialized variable?

Unspecified.

> E.g. for a bool, is it always true or false? For an int is it an integer
> value in [INT_MIN, INT_MAX]?

For anything but unsigned char, it may be a trap representation, which is
to say, accessing the value can cause undefined behavior.

(Actually, I'm not sure about bool.)

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Eric Sosman
Guest
Posts: n/a

 01-19-2010
On 1/19/2010 12:20 PM, Datesfat Chicks wrote:
> [...]
> Usually, the value of an automatic variable, unless it is a pointer and
> you dereference it, is something that is simply a pseudo-random data
> value and it won't do any harm to simply access the value or output it
> using printf(). The reason for this is that in any machine
> representation, typically all possible bit patterns mean SOMETHING.

One such SOMETHING is "signalling NaN," for most systems.

> [...]
> I believe that some coding standards require initializers on all
> automatics. The cost in extra code may be justified by the reduction in
> the probability of a certain class of bug.

There may well be such standards. IMHO they are wrong-
Compilers and lints can do enough analysis to tell whether a
path exists that might cause a variable to be read before it
is written, and will issue warning messages if such paths
are found. But if the variable is initialized the diagnostics
are suppressed, and all you get is a wrong answer at run-time.
the bug -- but it's less helpful than having the bug pointed
out to you at compile time.

--
Eric Sosman
(E-Mail Removed)lid

Tim Rentsch
Guest
Posts: n/a

 01-19-2010
Nick Keighley <(E-Mail Removed)> writes:

> On 19 Jan, 11:05, Philipp Klaus Krause <(E-Mail Removed)> wrote:
>
>> What's the value of an uninitialized variable?

>
> assuming you're talking about automatic variables (see Richard's post)
> then the value is undefined. The standard allows "trap values" and
> attempts to read a trap value will cause the program to fail.
>
>> E.g. for a bool, is it always true or false?

>
> no.
>
>> For an int is it an integer value in [INT_MIN, INT_MAX]?

>
> no
>
> but if it makes you any happier unsigned char is an exception in that
> it cannot be a trap value. I'm guessing that all bit patterns are
> hence valid values.

Under C1X, even unsigned chars can cause traps if unitialized.
(And there are even real machines that do, which is why the
behavior was changed.)

Ben Bacarisse
Guest
Posts: n/a

 01-19-2010
Seebs <(E-Mail Removed)> writes:

> On 2010-01-19, Philipp Klaus Krause <(E-Mail Removed)> wrote:
>> What's the value of an uninitialized variable?

>
> Unspecified.
>
>> E.g. for a bool, is it always true or false? For an int is it an integer
>> value in [INT_MIN, INT_MAX]?

>
> For anything but unsigned char, it may be a trap representation, which is
> to say, accessing the value can cause undefined behavior.
>
> (Actually, I'm not sure about bool.)

I can't see any wording that might exempt _Bool from having trap
reps. That's not a proof, of course, but where do your doubts come
from?

--
Ben.

Seebs
Guest
Posts: n/a

 01-19-2010
On 2010-01-19, Ben Bacarisse <(E-Mail Removed)> wrote:
> I can't see any wording that might exempt _Bool from having trap
> reps. That's not a proof, of course, but where do your doubts come
> from?

Imagine if you will a _Bool bitfield (I *think* those got officially
tacked on at some point?) with only one bit. We know it holds two
values. We know it has two valid values. I don't think it can have
a trap representation.

In practice, though, I don't see any guarantees, and a non-bitfield
_Bool could presumably have as a trap representation "anything but 0 or
1". Thus, if you assigned 23 to it, the compiler would generate code
to change that silently to a 1 (because true is always exactly 1),
but if you memcpy'd 23 over it, it would be a trap representation.

This would most likely require extra code to set up in the compiler, but
it might be sorta cool. Certainly, it would lead to another generation of
insanely complicated #defines for "true".

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Ben Bacarisse
Guest
Posts: n/a

 01-19-2010
Seebs <(E-Mail Removed)> writes:

> On 2010-01-19, Ben Bacarisse <(E-Mail Removed)> wrote:
>> I can't see any wording that might exempt _Bool from having trap
>> reps. That's not a proof, of course, but where do your doubts come
>> from?

>
> Imagine if you will a _Bool bitfield (I *think* those got officially
> tacked on at some point?) with only one bit. We know it holds two
> values. We know it has two valid values. I don't think it can have
> a trap representation.

I am getting lost. That's an argument that bools with only one bit
can't have trap reps. I agree. You seemed unwilling to assert that
bool can have trap reps. Maybe I miss-understood your "I am not sure
about bool". You've snipped it, so the context is getting lost.

> In practice, though, I don't see any guarantees, and a non-bitfield
> _Bool could presumably have as a trap representation "anything but 0 or
> 1". Thus, if you assigned 23 to it, the compiler would generate code
> to change that silently to a 1 (because true is always exactly 1),
> but if you memcpy'd 23 over it, it would be a trap representation.

Yes, this seems eminently possible. I thought you were not sure that
this was possible.

<snip>
--
Ben.