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!
next prev parent 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).