Groups | Search | Server Info | Login | Register

Groups > comp.lang.c > #391390

Re: int a = a

Show key headers only | View raw

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

[how to indicate a variable not being used is okay]
[some quoted text rearranged]

> Unless I'm missing something, `(void)x` also has undefined beahvior
> if x is uninitialized,

Right.  Using (void)&x is better.

> though it's very likely to do nothing in practice.

Unless x is volatile qualified, in which there must be an access
to x in the generated code.

> The behavior [of int a = a;] is undefined.  In C11 and later
> (N1570 6.3.2.1p2):
>
>     Except when [...] an lvalue that does not have array type is
>     converted to the value stored in the designated object (and is
>     no longer an lvalue); this is called lvalue conversion.
>     [...]
>     If the lvalue designates an object of automatic storage
>     duration that could have been declared with the register
>     storage class (never had its address taken), and that object
>     is uninitialized (not declared with an initializer and no
>     assignment to it has been performed prior to use), the
>     behavior is undefined.

> Long digression follows.
>
> The "could have been declared with the register storage class"
> seems quite odd.  And in fact it is quite odd.

I don't have the same reaction.  The point of this phrase is that
undefined behavior occurs only for variables that don't have
their address taken.  The phrase used describes that nicely.
Any questions related to "registerness" can be ignored, because
'register' in C really has nothing to do with hardware registers,
despite the name.

> It's tempting to assume that `int n = n;` did not have undefined
> behavior prior to C11, or that accessing an automatic object whose
> address has not been taken does not have undefined behavior even
> in C11 or later, but it's not that simple.
>
> In C90, the non-normative Annex G (renamed to Annex J in later
> editions) says:
>
>     The behavior in the following circumstances is undefined:
>     [...]
>     - The value of an uninitialized object that has automatic storage
>       duration is used before a value is assigned (6.5.7).
>
> 6.5.7 discusses initialization, and says that "If an object that
> has automatic storage duration is not initialized explicitly, its
> value is indeterminate", and C90's definition of "undefined behavior"
> explicitly refers to use of indeterminately valued objects, though
> it's not 100% clear that using an indeterminate value *always*
> has undefined behavior.
>
> So in C90, `int n = n;` explicitly had undefined behavior, even if
> all possible bit representations for an object of type int correspond
> to valid values (C90 didn't mention "trap representations").
>
> C99 added a definition for "indeterminate value":  "either an
> unspecified value or a trap representation", and drops the mention
> of indeterminate values in the definition of "undefined behavior".
> It dropped the reference to uninitialized objects in Annex G/J.
> I believe that in C99, `int n = n;` is well defined *if* int
> has no trap representations, or if the representation stored in
> the memory occupied by n happens not to be a trap representation.
> If int has trap representations, and that memory happens to contain
> such a representation, the behavior is undefined.
>
> I found a discussion in comp.std.c from 2023, subject "Does reading
> an uninitialized object have undefined behavior?".
>
> The discontinued IA-64/Itanium processor had something called
> "NaT", "Not a Thing".  NaT representations exist only in CPU
> registers, not in memory.  (Imagine an extra bit for each register
> indicating whether the register contains a "thing".)  A NaT allows
> for representations that act like C trap representations (called
> non-value representations in C23) even for types with no trap
> representations (for example where all 2**N possible representations
> correspond to valid values) -- but again, only in CPU registers.
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_338.htm
>
> So the "could have been declared with the register storage class"
> wording was added in C11 specifically to cater to the IA64.  This
> change would have been superfluous in C90, where the behavior was
> undefined anyway, but is a semantically significant change between
> C99 and C11.  (If some future CPU has something like NaT that can
> be stored in memory, the wording might need to be updated yet again.)
>
> My takeaway is that if it requires this much research to determine
> whether accessing the value of an uninitialized object has undefined
> behavior (in which circumstances and which edition of the standard),
> I'll just avoid doing so altogether.  I'll initialize objects
> when they're defined whenever practical.  If it's not practical
> for some reason, I won't initialize it with some dummy value;  I'll
> leave it uninitialized so the compiler has a chance to warn me if
> I accidentally use it before assigning a value to it.

I think you are overthinking the question.  In cases where it's
important to give an initial value to a variable, and can be done
so at the point of its declaration, use an initializer;  otherwise
don't.  We don't have to read several different C standards, or
even only one, to reach that conclusion.  If someone wants to know
exactly which border cases are safe and which cases are not, then
reading the relevant version(s) of the C standard is needed, but
in most situations it isn't.  It's important for the C standard to
be precise about what it prescribes, but as far as initialization
goes it's easy to write code that doesn't need that level of
detail.  Compiler writers need to know such things;  in the
particular case of when and where to initialize, most developers
don't.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Bart's Language bart <bc@freeuk.com> - 2025-03-17 23:51 +0000
  Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-18 12:17 +0000
    Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 13:54 +0000
      Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-18 15:10 +0000
        Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 15:45 +0000
          Re: Bart's Language David Brown <david.brown@hesbynett.no> - 2025-03-18 17:31 +0100
            int a = a (Was: Bart's Language) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-18 18:04 +0000
              Re: int a = a (Was: Bart's Language) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-18 19:36 +0100
                Re: int a = a (Was: Bart's Language) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-18 19:11 +0000
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 15:56 +0100
                Re: int a = a (Was: Bart's Language) scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 16:38 +0000
                Re: int a = a (Was: Bart's Language) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-19 14:29 -0700
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 09:39 +0100
                Re: int a = a (Was: Bart's Language) bart <bc@freeuk.com> - 2025-03-20 11:59 +0000
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 15:46 +0100
                Re: int a = a (Was: Bart's Language) wij <wyniijj5@gmail.com> - 2025-03-20 23:13 +0800
                Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 02:02 -0700
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 15:57 +0100
                Re: int a = a (Was: Bart's Language) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-19 17:07 +0000
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 13:34 -0700
                Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 02:54 -0700
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 03:20 -0700
                Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-20 16:22 +0100
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 12:46 -0700
                Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-21 10:44 +0100
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-21 12:23 -0700
                Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-21 21:46 +0100
                Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 13:59 -0700
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-22 15:37 -0700
                Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-20 15:42 +0100
              Re: int a = a (Was: Bart's Language) scott@slp53.sl.home (Scott Lurndal) - 2025-03-18 19:37 +0000
              Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-18 20:51 +0100
                Re: int a = a (Was: Bart's Language) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-18 23:27 +0100
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 11:40 +0100
              Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-18 23:52 -0700
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 01:55 -0700
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 11:43 +0100
                Re: int a = a (Was: Bart's Language) Rosario19 <Ros@invalid.invalid> - 2025-03-19 13:23 +0100
                Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 01:32 -0700
          Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-20 22:55 +0000
            Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 16:22 -0700
              Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-22 14:37 +0000
                Re: Bart's Language James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-22 11:41 -0400
                Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-22 16:52 +0000
                Re: Bart's Language James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-22 20:12 -0400
                By definition... (Was: Bart's Language) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-23 17:20 +0000
        Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 22:19 +0000
          Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-20 22:38 +0000
            Re: Bart's Language Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-20 23:45 +0000
              Re: Bart's Language bart <bc@freeuk.com> - 2025-03-21 00:56 +0000
                Re: Bart's Language Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-21 17:47 +0000
                Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 07:12 -0700
            Re: Bart's Language bart <bc@freeuk.com> - 2025-03-21 00:33 +0000

csiph-web