Uninitialized auto variables

[Robert Gamble]

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

 

[Army1987]

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

 

[David Thompson]

Spoon wrote:

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

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