Re: int a = a (Was: Bart's Language)

scott@slp53.sl.home (Scott Lurndal) writes:

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

On 18/03/2025 19:36, Janis Papanagnou wrote:
>

On 18.03.2025 19:04, Kenny McCormack wrote:
>

In article <vrc75b$2r4lt$1@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
...
>

gcc won't warn until you say '-Wextra', and then only for:
>
    int a = a + 1;

>
People would not normally write "int a = a;".  It is used as a
common idiom meaning "I know it is not clear to the compiler
that the variable is always initialised before use, but /I/ know
it is - so disable the use-without-initialisation warnings for
this variable".

>
Wow! - It would never have occurred to me that "int a = a;" being
considered an idiom, let alone a "common idiom".

>
It is certainly an idiom, and certainly viewed by gcc as a way to
avoid an "uninitialized" warning (unless "-Winit-self" is also
enabled), and it is an idiom I have seen documented in at least one
other compiler (though I can't remember which - I've read many
compiler manuals over the decades).
>
But judging from the posts here, it may not be a "common" idiom.
>
(And I am not suggesting it is a /good/ idiom.  It's not one I use
myself, and I have "-Winit-self" in my list of standard warning
flags because it is conceivable that I write "int a = a;" in error.
But there are lots of idioms and common practices in C that I don't
like personally.)
>
>
As far as I understand it (and I hope to be corrected if I am
wrong), "int a = a;" is not undefined behaviour as long as the
implementation does not have trap values for "int".  It simply
leaves "a" as an unspecified value - just like "int a;" does.  Thus
it is not in any way "worse" than "int a;" as far as C semantics
are concerned.  Any difference is a matter of implementation - and
the usual implementation effect is to disable "not initialised"
warnings.
>
It is in much the same category as "(void) x;", which is an idiom
for skipping an "unused variable" or "unused parameter" warning.

>
I would disagree with this last statement.  (void)x is genuinely
useful and has no ill side effects.   'int a = a;' is exactly
the opposite - not useful and has potenial bad side effects.

I concur except that I recommend using (void)&x rather than (void)x,
because (void)&x is safer.  If x is volatile qualified, for example,
the expression (void)x actually does something, and must not be
compiled away, whereas (void)&x does not have these properties.