Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Uninitialized auto variables

Reply
Thread Tools

Uninitialized auto variables

 
 
pete
Guest
Posts: n/a
 
      07-30-2007
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
 
Reply With Quote
 
 
 
 
Spoon
Guest
Posts: n/a
 
      07-30-2007
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.
 
Reply With Quote
 
 
 
 
CryptiqueGuy
Guest
Posts: n/a
 
      07-30-2007
On Jul 30, 3:32 pm, Pietro Cerutti <(E-Mail Removed)> 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.


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

 
Reply With Quote
 
Pietro Cerutti
Guest
Posts: n/a
 
      07-30-2007
CryptiqueGuy wrote:
> On Jul 30, 3:32 pm, Pietro Cerutti <(E-Mail Removed)> 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.

>
>>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
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      07-30-2007
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/

 
Reply With Quote
 
Spoon
Guest
Posts: n/a
 
      07-30-2007
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.
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      07-30-2007
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.

 
Reply With Quote
 
Harald van =?UTF-8?B?RMSzaw==?=
Guest
Posts: n/a
 
      07-30-2007
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.
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      07-30-2007
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.

 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      07-31-2007
On Mon, 30 Jul 2007 12:32:41 +0200, Pietro Cerutti <(E-Mail Removed)>
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Auto Shipping Auto Shipping Scheduling:car moving auto transport linkswanted ASP .Net 1 11-22-2013 07:02 AM
Eclipse bug: Doesn't check for uninitialized variables when there are "too many" variable declarations. Oliver Wong Java 11 04-19-2006 09:40 AM
Using explicitly sized variables in functions as auto variables or parameters Adel C Programming 3 03-17-2005 04:36 AM



Advertisments