Uninitialized auto variables

[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.

[Chris Dollin]

Spoon wrote:

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.)

--
Far-Fetched Hedgehog
"We did not have time to find out everything we wanted to know."
- James Blish, /A Clash of Cymbals/

[santosh]

Spoon wrote:

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

[Mark Bluemel]

Spoon wrote:

Richard Tobin wrote:

>In article <46***********************@news.free.fr>,
Spoon <root@localhostwrote:

>>... 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()"?

I only needed one identifier per run.

If there's only one, why do you need it at all? I don't need to be able
to differentiate myself from myself.

[Pietro Cerutti]

santosh wrote:

Spoon wrote:

>Hello everyone,

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

Yes.

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!

>

>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

--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

[pete]

Spoon wrote:

>
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.

--
pete

[Spoon]

pete wrote:

Spoon wrote:

>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).
*/

(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;
}

--
Regards.

[CryptiqueGuy]

On Jul 30, 3:32 pm, Pietro Cerutti <[e-mail]:

santosh wrote:

Spoon wrote:

Hello everyone,

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

Yes.

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.

[Pietro Cerutti]

CryptiqueGuy wrote:

On Jul 30, 3:32 pm, Pietro Cerutti <[e-mail]:

>santosh wrote:

>>Spoon wrote:
Hello everyone,
I suppose using uninitialized automatic integer variables leads
to undefined behavior?
Yes.

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.

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

--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

[Chris Dollin]

Spoon wrote:

pete wrote:

>Spoon wrote:

>>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).
*/

(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.

--
Far-Fetched Hedgehog
Notmuchhere: http://www.electrichedgehog.net/

[Spoon]

Chris Dollin wrote:

Spoon wrote:

>pete wrote:

>>Spoon wrote:

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).
*/

(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.

Doh! Yes, I meant bar2.

The signedness has nothing to do with it.

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

[Chris Dollin]

Spoon wrote:

Chris Dollin wrote:

>Spoon wrote:

>>pete wrote:

Spoon wrote:

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).
*/
(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.

Doh! Yes, I meant bar2.

>The signedness has nothing to do with it.

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.]

--
Far-Fetched Hedgehog
The shortcuts are all full of people using them.

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

Chris Dollin wrote:

Spoon wrote:

>Chris Dollin wrote:

>>Spoon wrote:

pete wrote:

Spoon wrote:
>
>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).
*/
(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.

Doh! Yes, I meant bar2.

>>The signedness has nothing to do with it.

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

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.

[Chris Dollin]

Harald van Dijk wrote:

Chris Dollin wrote:

>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.

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.

--
Determined Hedgehog
Nit-picking is best done among friends.

[Barry Schwarz]

On Mon, 30 Jul 2007 12:32:41 +0200, Pietro Cerutti <ga**@gahr.ch>
wrote:

>santosh wrote:

>Spoon wrote:

>>Hello everyone,

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

Yes.

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

[Robert Gamble]

On Jul 30, 10:41 pm, Barry Schwarz <[e-mail]:

On Mon, 30 Jul 2007 12:32:41 +0200, Pietro Cerutti <[e-mail]>
wrote:

santosh wrote:

Spoon wrote:

>Hello everyone,

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

Yes.

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.

Appendix J is non-normative, the Standard doesn't contain any backing
normative text in this case. An indeterminate value is defined as
either an unspecified value or a trap representation. An unspecified
value is a valid value, a trap representation is not. If the type in
question does not have any trap representations it follows that an
indeterminate value for that type can only be an unspecified value for
which UB is not invoked by accessing it. For example it is never UB
to access the value of an uninitialized unsigned char variable.

Robert Gamble

[CBFalconer]

Richard Tobin wrote:

Spoon <root@localhostwrote:

.... snip ...

>

>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()"?

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

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

[Army1987]

On Mon, 30 Jul 2007 12:52:49 +0200, Spoon wrote:

pete wrote:

>Spoon wrote:

>>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).
*/

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

In C89, using indeterminate values causes UB by itself.
In C99 it does only if it is a trap representation, so if you can
be sure that there are no traps, e.g. INT_MAX - INT_MIN + 1 is
2**(CHAR_BIT * sizeof(int), it won't cause UB. But what do you
need to do? On many system uninitialized variables tend to be
almost always zero, that's even worse that the worst
implementation of rand().
--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

[David Thompson]

On Mon, 30 Jul 2007 14:16:37 +0530, santosh <sa*********@gmail.com>
wrote:

Spoon wrote:

<snip>

I sometimes [use uninit auto] 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

If 'any int' means every value of type 'int' is to be possible, rand()
won't do that -- it gives you at most half the range, and possibly
much less (e.g. int is 1+31 bits and RAND_MAX is still 32767).

If 'any int' just means that the value is to be _some_ 'int' value, as
previously noted, 0 is fine. But 42 is even finer.

Aside: not all C platforms have a 'man' command -- and among those
that do, I have discovered to my great (but offtopic) surprise and
disappointment, not all support the <secnum<topicsyntax.

- formerly david.thompson1 || achar(64) || worldnet.att.net