Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.c > #392983

Re: int a = a

Show all headers | View raw

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> [...]I believe it would be much simpler and clearer if attempting
>>>> to read an uninitialised and unassigned local variable were
>>>> undefined behaviour in every case.
>>>
>>> I probably agree (I haven't given it all that much thought), but
>>> the committee made a specific decision between C90 and C99 to say
>>> that reading an uninitialized automatic object is *not* undefined
>>> behavior.  I'm don't know why they did that (though, all else
>>> being equal, reducing the number of instances of undefined
>>> behavior is a good thing), but reversing that decision for this
>>> one issue is not something they decided to do.
>>
>> Your description of what was done is wrong.  It is still the case in
>> C99 that trying to access an uninitialized object is undefined
>> behavior, at least potentially, except for accesses using a type
>> that either is a character type or has no trap representations (and
>> all types other than unsigned char may have trap representations,
>> depending on the implementation).  A statement like
>>
>>     int a = a;
>>
>> may still be given a warning as potential undefined behavior, even
>> in C99.
>
> I had already mentioned that distinction earlier in the thread.

Oh, I must have missed that.  I don't remember seeing it in
the message I was replying to.

>> The mistake is thinking that UB for uninitialized access was
>> removed in C99.  It wasn't.  Narrowed, yes;  removed, no.
>
> Acknowledged.

Good deal.

Back to comp.lang.c | Previous | Next | Find similar

Thread

Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-28 09:39 -0700

csiph-web