Re: __attribute__ to selectively disable -Wmaybe-uninitialized

[mark_at_yahoo <markrubn@yahoo.com>]

(Apologies for the delayed response. I receive gcc-help posts, including 
others from you, without problem, but this one which I'm particularly 
interested got caught in my spam filters.)

On 10/24/20 11:32 AM, Segher Boessenkool wrote:
> 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).

FWIW, I agree.


> "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.

I always factor out common code, and attempt to give it informative 
function/class/method/namespace/etc names.

I tend *not* to factor out code that is only used in one place merely to 
follow coding standards that forbid lengthy functions. No spaghetti 
code, but I have no problem with:

     void func()
     {
         // part1
         // ...

         // part2
         // ...

         // part3
         // ...
     }

compared to:

     void func()
     {
         part1();
         part2();
         part3();
     }

regardless how long the "parts" are (assuming they aren't reused elsewhere).

And, yes, I understand inline functions.


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

Whether or not it gives false positives seems unpredictable. My code's 
control flow is:

     void func(
     bool    with_buffer)
     {
         char        *buffer;

         if (with_buffer)
             buffer = allocate();

         while (still_working()) {
             other_processing();

             if (with_buffer)
                 process_buffer(buffer);

             yet_more_processing();
         }
     }

This test demo does not give the warning. The real program, with 
identical control flow but much more intermediate code, does.

Yes, there are many ways to refactor this code (separate "with" and 
"without" functions, two different loops inside "if" and "else" branches 
of "if (with_buffer)", etc).  IMO all of them obfuscate the above simple 
control flow, not the opposite.


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

I thought we agreed that warnings are A Good Thing.


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

FWIW, I'm using -Wextra. As per above, I like warnings.


> 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.

The comment was "Why don't just initialize the variable?". In addition 
to the unnecessary compiled instructions that produces (unless the 
optimizer is smarter than the warning generator and removes them), it 
hides the issue in a non-obvious way compared to the explicit pragmas or 
a theoretical attribute.

As you point out, that's been the only comment in 8 years until this 
discussion -- and I do consider it a discussion, not a "complaint". As 
you said before, the issue is still open. I considered the comment a 
"last word", which along with lack of further response to the original 
issue filer's further points to mean, "we feel this is not 
needed/important". Whether that's "dismissive" or not is open to 
interpretation.


> 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).  

Of course.


> It
> does not have to become part of GCC mainline.  *That* is the nature of
> Free Software.

I'm suggesting the attribute because I want to use it in some 
open-source software I'm distributing. I also think it would be a good 
GCC extension in general. Even assuming I had the ability to implement 
it myself or contract the same, I will not be distributing a custom 
compiler for my project, so if it wouldn't make it into the mainline 
(which these emails strongly suggest), that's not an option.


> If you cannot convince people to spend their time on
> implementing your ideas, then maybe they do not think those are good
> ideas?

Obviously they/you don't. Pending any further comments regarding my 
control flow example above, I'll take it that I wasn't convincing and 
the matter is closed. I do take heart that others (like the 2012 issue 
filer and some in this short thread) seem to agree with me, or at least 
that this has been worth discussing.