Re: int a = a

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

>
I'm not convinced -- and it's far less idiomatic.

Both phrases are idiomatic.  What you mean is one phrase is more
common than the other.  More common doesn't mean better.  Recall
Dijkstra's dictum, not to conclude that something is more convenient
just because it's more conventional.

I don't think
I've ever seen (void)&x in code, and if I did I'd wonder what the
author's intent was.

The same is true for any construction seen for the first time,
and like other such cases either you would figure it out or
look/ask around to find out.  And then you'd know.

Furthermore, having gotten the benefit of this discussion, you
wouldn't have to do that, because you've seen it already.

(void)x is a common idiom for hinting to the compiler that it
doesn't need to complain about x being unused.  (void)&x doesn't
tell the compiler that the *value* of x is used.  I'm not sure how
much difference that makes.

Both have the effect of getting rid of the warning even if placed
after a 'return' statement so as not to be executed.

Even with (void)x and/or (void)&x, a compiler *could* still warn
about x being unused, or about the programmer's use of an ugly font.

Yes, it could.  At such time that it happens I expect I would
react and adapt accordingly, the same as with all questionable
compiler behaviors.

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.

>
DR 338 is explicitly motivated by an IA-64 feature that applies only to
CPU registers.  An object whose address is taken can't be stored (only)
in a register, so it can't have a NaT representation.
>
The phrase used is "could have been declared with register storage class
(never had its address taken)".  Surely "never had its address taken"
would have been clear enough if CPU registers weren't a big part of the
motivation.

I'm surprised you would say this.  The phrase "never had its address
taken" doesn't satisfy the careful language threshold observed in
the ISO C standard.  Do you really not understand this?

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.

>
My overthinking led me to essentially the same conclusion, so I don't
see the problem.  And I also found it to be an interesting exploration
of how certain aspects of the C standard have evolved over time.

Doing more thinking than is needed is a waste of effort.  I can only
hope that you have better things to do with your time.  Furthermore
spending any time dwelling on the Itanium being the motivation for
the change is just a distraction.  It was interesting to learn, but
having learned it there is no need to consider it further.

        We don't have to read several different C standards, or
even only one, to reach that conclusion.

>
No, but we do have to read one or more C standards to counter an
argument that `int a = a;` is well defined.

Only if one feels it necessary to convince someone who holds such
an uneducated view.  I don't mind pointing someone in the right
direction, but it's not my job to convince them.

                                          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.

>
Most developers don't read this newsgroup.

Probably true, but there plenty of places where one can find out
these things besides comp.lang.c.