Re: int a = a

On 21/03/2025 20:23, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

I see that, but 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.

Certainly the C committee have to think harder, and consider more possibilities than most mere C programmers are likely to do - and they don't like to make something "undefined" if it were defined (to at least some extent) previously.
I can agree that it is good to reduce the number of UB's, all else being equal - but all else is very seldom equal.  To me, it is preferable to say clearly and explicitly "this is undefined behaviour" than to leave the C programmer to combine several parts of the standard to figure out that the construct might do something defined but unspecified, or might do something bad (a trap), or might be defined or undefined depending on other mostly unrelated code.
I am a fan of clear undefined behaviour when there is no good definition of what the behaviour should be - I'd rather have UB than badly defined behaviour.  But I strongly prefer it to be explicit and clear.

 

Alternatively, it could have said that the value is unspecified in
every case.  Then on the IA-64, the compiler would have to ensure that
registers do not have their NaT bit set even if they are not
initialised - this would not be a difficult task.  Enabling use of the
NaT bit for detection of bugs could then be a compiler option if
implementations wanted to provide that feature.

 The whole point of the NaT bit is to detect accesses to uninitialized
values.  Requiring the compiler to arbitrarily clear that bit
doesn't strike me as a good idea.
 

I think it would be fine to do that - as long as tools also provide modes that don't clear the bit so that you can use the feature for debugging or run-time checks.  If the behaviour here was to make the variable an unspecified value, then in fully compliant modes the compiler would have to clear the NaT bit, so the compiler mode making use of the NaT bit would be marginally non-compliant.  But I see no problem with that - developers can happily use slightly non-compliant mode in order to get more features (language extensions, faster execution, better debugging - whatever suits the user and the compiler implementer).
Still, leaving it undefined behaviour would be even better, because then compilers could have flags for using the NaT bit, or clearing the variable to 0, or giving a compile-time error - whatever they did it would still be compliant.

I dislike the way that wording was added to the standard specifically
to cater to one specific CPU (which happens to have been discontinued
later).  I would have been happier with a more general solution.
I that making accessing the value of an uninitialized automatic
object UB would have been much cleaner, and it would have allowed for
sensible use of NaT by IA-64 compilers.  But without knowing *why*
the committee removed that UB between C90 and C99, I'm hesitant to
say it was a mistake.
 Meanwhile, I will in effect assume that accessing uninitialized objects
is UB, i.e., I'll carefully avoid doing so.
 

That, I think is the best way to handle this.