Re: __attribute__ to selectively disable -Wmaybe-uninitialized

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 23, 2020 at 02:51:31PM -0700, mark_at_yahoo via Gcc-help wrote:
> On 10/23/20 1:38 PM, Segher Boessenkool wrote:
> >Yes.  And you usually should make trivial changes to your program if the
> >compiler warns, even if you consider that unnecessary -- just so that
> >you will not miss other warnings!
> 
> >No, but you can write your code so that it more obviously does not use
> >unitialised variables.  This is an Even Better Thing(tm).  The compiler
> >will understand it, but much more importantly, human readers will
> >understand it as well!
> 
> It's often (maybe always) possible to reorder/refactor the code as you 
> suggest. Sometimes (maybe often) that results in convoluted logic and 
> control flow, needlessly repeated code sections, gratuitous (possibly 
> inline) functions, and the like. The cure being worse than the #pragma 
> disease.

I have to disagree with you there.  Well-factored code is *good*.  The
compiler can (and will) do all the obvious optimisations; you should not
obfuscate your program by doing them manually (and hinder the compiler's
optimisers, and introduce bugs at the same time).

"Gratuitous functions" is only a problem if you have trouble naming
them.  Which sometimes is a problem, sure, but most of the time that
simply shows that your factoring isn't so good.

-Wmaybe-uninitialized only has false positives for non-trivial control
flow.  Which you probably shouldn't have in your source code anyway.


If you insist on using constructs that -Wmaybe-uninitialized cannot
handle, then do not use -Wmaybe-uninitialized?


> >-Wmaybe-uninitialized has a LOT of false positives if you use anything
> >but the strictest, simplest control flow.  It's the nature of the beast.
> 
> That's the point. There will always be false positives. Sometimes the 
> programmer *does* know more than the compiler. IMO GCC could benefit 
> from a better way to selectively turn them off.

It should arguably not be enabled by -Wall, just by -Wextra.

> >>5. I now see something similar was requested in 2012 in
> >>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 but seems to have
> >>been dismissed with a variation of #4.
> >
> >It wasn't dismissed, that PR is still open.
> 
> Sorry, I was using "dismissed" colloquially. The response was 
> dismissive, and from what I've been able to find nothing has been done 
> in the succeeding 8 years.

The only comment was a helpful suggestion.  If that is not what you are
looking for, just ignore it, or make a comment yourself?  Complaining
that people are "dismissive" because they have a different opinion is
not helpful.

> But, yes, that's the nature of the open source (in general) and GCC (in 
> particular) beast.

Uh-huh.

If you insist on having an attribute to disable just this warning, you
can implement it yourself (or get someone else to do it for you).  It
does not have to become part of GCC mainline.  *That* is the nature of
Free Software.  If you cannot convince people to spend their time on
implementing your ideas, then maybe they do not think those are good
ideas?


Segher



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux