public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: NightStrike <nightstrike@gmail.com>
To: David Brown <david@westcontrol.com>
Cc: Alejandro Colomar <alx.manpages@gmail.com>,
	Andrew Pinski <pinskia@gmail.com>,
	 "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Martin Uecker <uecker@tugraz.at>,
	 Joseph Myers <joseph@codesourcery.com>
Subject: Re: [BUG] -Wuninitialized: initialize variable with itself
Date: Mon, 14 Nov 2022 12:43:33 -0500	[thread overview]
Message-ID: <CAF1jjLuKQPQ69+t=Vb7XLpY7Drvp9FYgrEV402Nvw8=2JVqzHQ@mail.gmail.com> (raw)
In-Reply-To: <f6cf2e82-6649-bdab-1021-3d9ecb4fd81f@westcontrol.com>

[-- Attachment #1: Type: text/plain, Size: 2999 bytes --]

On Mon, Nov 14, 2022, 10:49 David Brown <david@westcontrol.com> wrote:

>
>
> On 14/11/2022 16:10, NightStrike wrote:
> >
> >
> > On Mon, Nov 14, 2022, 04:42 David Brown via Gcc <gcc@gcc.gnu.org
>
> >
> >     Warnings are not perfect - there is always the risk of false
> positives
> >     and false negatives.  And different people will have different ideas
> >     about what code is perfectly reasonable, and what code is risky and
> >     should trigger a warning.  Thus gcc has warning flag groups (-Wall,
> >     -Wextra) that try to match common consensus, and individual flags for
> >     personal fine-tuning.
> >
> >     Sometimes it is useful to have a simple way to override a warning in
> >     code, without going through "#pragma GCC diagnostic" lines (which are
> >     powerful, but not pretty).
> >
> >     So if you have :
> >
> >              int i;
> >              if (a == 1) i = 1;
> >              if (b == 1) i = 2;
> >              if (c == 1) i = 3;
> >              return i;
> >
> >     the compiler will warn that "i" may not be initialised.  But if you
> >     /know/ that one of the three conditions will match (or you don't care
> >     what "i" is if it does not match), then you know your code is fine
> and
> >     don't want the warning.  Writing "int i = i;" is a way of telling the
> >     compiler "I know what I am doing, even though this code looks dodgy,
> >     because I know more than you do".
> >
> >     It's just like writing "while ((*p++ = *q++));", or using a cast to
> >     void
> >     to turn off an "unused parameter" warning.
> >
> >
> > Wouldn't it be easier, faster, and more obvious to the reader to just
> > use "int i = 0"? I'm curious what a real world use case is where you
> > can't do the more common thing if =0.
> >
>
> You can write "int i = 0;" if you prefer.  I would not, because IMHO
> doing so would be wrong, unclear to the reader, less efficient, and
> harder to debug.
>
> In the code above, the value returned should never be 0.  So why should
> "i" be set to 0 at any point?  That's just an extra instruction the
> compiler must generate (in my line of work, my code often needs to be
> efficient).  More importantly, perhaps, it means that if you use
> diagnostic tools such as sanitizers you are hiding bugs from them
> instead of catching them - a sanitizer could catch the case of "return
> i;" when "i" is not set.
>
> (I don't know if current sanitizers will do that or not, and haven't
> tested it, but they /could/.)
>
> But I'm quite happy with :
>
>         int i = i;      // Self-initialise to silence warning
>
> I don't think there is a "perfect" solution to cases like this, and
> opinions will always differ, but self-initialisation seems a good choice
> to me.  Regardless of the pros and cons in this particular example, the
> handling of self-initialisation warnings in gcc is, AFAIUI, to allow
> such code for those that want to use it.


Thanks for the extended explanation, insight,  and detail!

  reply	other threads:[~2022-11-14 17:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-13 18:34 Alejandro Colomar
2022-11-13 18:40 ` Andrew Pinski
2022-11-13 18:41   ` Andrew Pinski
2022-11-13 18:43     ` Alejandro Colomar
2022-11-14  9:41       ` David Brown
2022-11-14 11:30         ` Alejandro Colomar
2022-11-14 15:10         ` NightStrike
2022-11-14 15:49           ` David Brown
2022-11-14 17:43             ` NightStrike [this message]
2022-11-13 18:45     ` Andrew Pinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF1jjLuKQPQ69+t=Vb7XLpY7Drvp9FYgrEV402Nvw8=2JVqzHQ@mail.gmail.com' \
    --to=nightstrike@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=david@westcontrol.com \
    --cc=gcc@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=pinskia@gmail.com \
    --cc=uecker@tugraz.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).