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 10:10:27 -0500	[thread overview]
Message-ID: <CAF1jjLuTkJP-kND02dDJ22ctnTbRgBjJfSyWOMAPR3pCkbBN-w@mail.gmail.com> (raw)
In-Reply-To: <18215302-3f22-e023-c188-d67b7e70dbff@westcontrol.com>

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

On Mon, Nov 14, 2022, 04:42 David Brown via Gcc <gcc@gcc.gnu.org> wrote:

> On 13/11/2022 19:43, Alejandro Colomar via Gcc wrote:
> > Hi Andrew!
> >
> > On 11/13/22 19:41, Andrew Pinski wrote:
> >> On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski <pinskia@gmail.com>
> wrote:
> >>>
> >>> On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
> >>> <gcc@gcc.gnu.org> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> While discussing some idea for a new feature, I tested the following
> >>>> example
> >>>> program:
> >>>>
> >>>>
> >>>>       int main(void)
> >>>>       {
> >>>>           int i = i;
> >>>>           return i;
> >>>>       }
> >>>
> >>> This is NOT a bug but a documented way of having the warning not
> >>> being there.
> >>> See
> >>>
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Winit-self
> >>>
> >>>
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wuninitialized
> >>>
> >>> "If you want to warn about code that uses the uninitialized value of
> >>> the variable in its own initializer, use the -Winit-self option."
> >>
> >> I should note the main reason why I Know about this is because I fixed
> >> this feature years ago (at least for C front-end)
> >> and added the option to disable the feature.
> >
> > I'm curious: what are the reasons why one would want to disable such a
> > warning?
> > Why is it not in -Wall or -Wextra?
> >
> > Thanks,
> >
> > Alex
> >
>
> 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.

>

  parent reply	other threads:[~2022-11-14 15:10 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 [this message]
2022-11-14 15:49           ` David Brown
2022-11-14 17:43             ` NightStrike
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=CAF1jjLuTkJP-kND02dDJ22ctnTbRgBjJfSyWOMAPR3pCkbBN-w@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).