Uninitialized auto variables

S

Spoon

Hello everyone,

I suppose using uninitialized automatic integer variables leads
to undefined behavior?

i.e.

int foo(void)
{
int bar; /* bar may be 0, or it may be non-0 */
return bar;
}

I sometimes do that when I need an int, any int.

I suppose this is a bad habit? :)

Regards.
 
C

Chris Dollin

Spoon said:
Hello everyone,

I suppose using uninitialized automatic integer variables leads
to undefined behavior?
Yes.

int foo(void)
{
int bar; /* bar may be 0, or it may be non-0 */
return bar;
}

I sometimes do that when I need an int, any int.

I suppose this is a bad habit? :)

Very.

(If "any int" will do, zero is a convenient value.)
 
S

santosh

Spoon said:
Hello everyone,

I suppose using uninitialized automatic integer variables leads
to undefined behavior?
Yes.

i.e.

int foo(void)
{
int bar; /* bar may be 0, or it may be non-0 */
return bar;
}

I sometimes do that when I need an int, any int.

I suppose this is a bad habit? :)

Yes. If you need a random integer, just use the rand Standard library
function.

man 3 rand
 
K

Keith Thompson

Spoon said:
I suppose using uninitialized automatic integer variables leads
to undefined behavior?

i.e.

int foo(void)
{
int bar; /* bar may be 0, or it may be non-0 */
return bar;
}

I sometimes do that when I need an int, any int.

I suppose this is a bad habit? :)

Yes.

What are the circumstances in which you need "an int, any int" but
don't care about the value?
 
S

Spoon

Keith said:
Yes.

What are the circumstances in which you need "an int, any int" but
don't care about the value?

For example, an opaque identifier. Any value will do.

I suppose rand() is a much better option.
 
R

Richard Tobin

What are the circumstances in which you need "an int, any int" but
don't care about the value?
[/QUOTE]
For example, an opaque identifier. Any value will do.

When do you need opaque identifiers but not care about whether they're
different? Why not just use "45576" instead of "foo()"?

-- Richard
 
S

Spoon

For example, an opaque identifier. Any value will do.

When do you need opaque identifiers but not care about whether they're
different? Why not just use "45576" instead of "foo()"?[/QUOTE]

I only needed one identifier per run.
(It didn't matter if it was the same identifier on the next run.)
I won't do it anymore, now that I know it leads to UB.
 
C

CBFalconer

Richard said:
.... snip ...


When do you need opaque identifiers but not care about whether
they're different? Why not just use "45576" instead of "foo()"?

For one reason, because the guaranteed minimum maximm integer value
is 32767.
 
P

Pietro Cerutti

santosh said:
Could you please point me to the paragraph of the standard where it's
told to be so?

I can only find this sentence in WG14/N1124, 6.2.4.5

"...The initial value of the object is indeterminate...."

Which doesn't mean, to my understanding, that using it invokes UB.

Thanks for clarifying this point!
 
P

pete

Spoon said:
Hello everyone,

I suppose using uninitialized automatic integer variables leads
to undefined behavior?

i.e.

int foo(void)
{
int bar; /* bar may be 0, or it may be non-0 */

/*
** The undefined part of the situation, is that bar may be (-0),
** and that the implementation may or may not trap on (-0).
*/
return bar;
}

I sometimes do that when I need an int, any int.

I suppose this is a bad habit? :)

You suppose correctly.
 
S

Spoon

pete said:
/*
** The undefined part of the situation, is that bar may be (-0),
** and that the implementation may or may not trap on (-0).
*/

(If it makes a difference, I use a C89 compiler.)

Does the problem remain with unsigned ints?

i.e.

unsigned foo2(void)
{
unsigned bar2; /* bar may be 0, or it may be non-0 */
return bar;
}
 
C

CryptiqueGuy

Could you please point me to the paragraph of the standard where it's
told to be so?

I can only find this sentence in WG14/N1124, 6.2.4.5

"...The initial value of the object is indeterminate...."

Which doesn't mean, to my understanding, that using it invokes UB.
From 6.2.6.1:

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.


Standards doesn't prohibit an uninitialized value to have a trap
representation. So it is a UB.
 
P

Pietro Cerutti

CryptiqueGuy said:
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.

Thank you!

And it's even more clearly stated in foot note 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."

Regards
 
C

Chris Dollin

Spoon said:
(If it makes a difference, I use a C89 compiler.)

Does the problem remain with unsigned ints?

i.e.

unsigned foo2(void)
{
unsigned bar2; /* bar may be 0, or it may be non-0 */
return bar;
}

Assuming `bar` was supposed to be `bar2`, that gets UB.
The signedness has nothing to do with it.
 
C

Chris Dollin

Spoon said:
Doh! Yes, I meant bar2.


I had the vague belief that trap representations were not allowed (?)
for unsigned integers.

I'm not sure that matters; doesn't the Standard say that the
mere use of an indeterminate value produces UB? (I can't
quickly find n689; the evil twin has a copy on his machine,
but he's not at work today.)

[At this moment I don't see why an implementation can't have
a /determinate/ bit for every object & value, independently
of any value bits those have, and do as it likes once it
finds a value with that bit unset.]
 
H

Harald van =?UTF-8?B?RMSzaw==?=

That's specific to unsigned char (and perhaps unsigned bit-fields; I haven't
checked). All other integer types are allowed to have trap representations.
I'm not sure that matters; doesn't the Standard say that the
mere use of an indeterminate value produces UB? (I can't
quickly find n689; the evil twin has a copy on his machine,
but he's not at work today.)

No, the standard doesn't say that anymore. C90 did, but when C99 added the
concept of trap representations, indeterminate values gave either an
unspecified value, or a trap representation. When there is no trap
representation, an indeterminate value is always a valid value.
[At this moment I don't see why an implementation can't have
a /determinate/ bit for every object & value, independently
of any value bits those have, and do as it likes once it
finds a value with that bit unset.]

This would be allowed in C90, but not in C99. I believe I've seen a request
for that to be permitted in the next standard again, however, because of
real implementation problems caused by unsigned char always having a valid
value.
 
C

Chris Dollin

Harald said:
No, the standard doesn't say that anymore. C90 did, but when C99 added the
concept of trap representations, indeterminate values gave either an
unspecified value, or a trap representation. When there is no trap
representation, an indeterminate value is always a valid value.

Ah. Mired in the past, that's me.
[At this moment I don't see why an implementation can't have
a /determinate/ bit for every object & value, independently
of any value bits those have, and do as it likes once it
finds a value with that bit unset.]

This would be allowed in C90, but not in C99. I believe I've seen a
request for that to be permitted in the next standard again, however,
because of real implementation problems caused by unsigned char always
having a valid value.

And, one would have thought, because one wants debugging implementations
to be able to catch the use of indeterminate values.

Thanks for the correction.
 
B

Barry Schwarz

Could you please point me to the paragraph of the standard where it's
told to be so?

I can only find this sentence in WG14/N1124, 6.2.4.5

"...The initial value of the object is indeterminate...."

Which doesn't mean, to my understanding, that using it invokes UB.

Thanks for clarifying this point!

It's covered in N1124, Appendix J.2, tenth item down.


Remove del for email
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top