__attribute__ to selectively disable -Wmaybe-uninitialized

__attribute__ to selectively disable -Wmaybe-uninitialized

[mark_at_yahoo]

To disable warnings of the form:
file.cxx:307:23: warning: 'buffer' may be used uninitialized in this 
function [-Wmaybe-uninitialized]

I have to bracket the variable's declaration, its use later in the 
function, and sometimes both, with:
#pragma GCC diagnostic push	
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
// code here
#pragma GCC diagnostic pop

The necessity to add many of these pragmas makes the code difficult to 
read. Is there a variable attribute that could be used instead, 
something like:
char	*buffer __attribute__((uninitialized));

I can't find anything similar in the "Common Variable Attributes" 
section of the docs.

If there isn't, could one be added? If local variables have attributes 
that are maintained throughout the compiler phases it seems it would be 
simple to check for one immediately before printing the warning, no 
matter how deep in the compilation process.

Notes:
1. I understand that -Wmaybe-uninitialized produces both false positives 
and false negatives.
2. Due to #1 it's difficult to produce a simple test demonstration.
3. I don't want to disable -Wmaybe-uninitialized globally, or for an 
entire function. Warnings are "A Good Thing"(tm).
4. Please, no lectures on why local variables should always be 
initialized at declaration.
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.

Thanks for any info.

-- 
MARK
markrubn@yahoo.com

Re: __attribute__ to selectively disable -Wmaybe-uninitialized

[Segher Boessenkool]

On Fri, Oct 23, 2020 at 01:01:13PM -0700, mark_at_yahoo via Gcc-help wrote:
> 3. I don't want to disable -Wmaybe-uninitialized globally, or for an 
> entire function. Warnings are "A Good Thing"(tm).

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!

> 4. Please, no lectures on why local variables should always be 
> initialized at declaration.

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!

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

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


Segher

Re: __attribute__ to selectively disable -Wmaybe-uninitialized

[mark_at_yahoo]

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.


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


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

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

-- 
MARK
markrubn@yahoo.com

Re: __attribute__ to selectively disable -Wmaybe-uninitialized

[J Decker]

--- Test.c -----
#include <stdio.h>
#include <stdlib.h>

void a( void ) {
   int buf[2];
   buf[0] = 0x12345678;
   buf[1] = 0x12345678;
}

void f( void ) {
   int n;
   int m;
   for( m = 0; m < 2; m++ ) {
      switch( m & 4 ) {
         case 1:
            n = 3;
            break;
      }
   }
   printf( "%d\n", n );
}

int main( void ) {
   a();
   f();
}
----

n is definitely never set, and I can't get a warning generated...
was more looking for a false-negative example (where N is definitely always
set by the usage...

it prints whatever buf[0] was set to in a()... (added A so it didn't print
0, and I could demonstrate some control; tried just doing a printf or
something before hand but ended up with '0' anyway, which looks sort of
like it might have been initialized to '0' (it wouldn't have been, but one
might feel that it did).

This is the sort of thing that happens... a series of events happen which
MUST happen before a thing is used, otherwise a return or other condition
which is not a direct test against that variables would trigger a bypass of
usage or early return...   I have several places where that warning has
shown up, and I've considered adding a fake initialization to a value that
I know would never be used and would always be replace by a real value (yes
it's only a couple ticks to set a variable, it's still a write to memory
that's not necessarily required; and who cares about generating heat?)

On Fri, Oct 23, 2020 at 2:51 PM mark_at_yahoo via Gcc-help <
gcc-help@gcc.gnu.org> 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.
>
>
> > -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.
>
>
> >> 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.
>
> But, yes, that's the nature of the open source (in general) and GCC (in
> particular) beast.
>
> --
> MARK
> markrubn@yahoo.com
>
>
>

Re: __attribute__ to selectively disable -Wmaybe-uninitialized

[Florian Weimer]

* mark at yahoo via Gcc-help:

> The necessity to add many of these pragmas makes the code difficult to
> read. Is there a variable attribute that could be used instead, 
> something like:
> char	*buffer __attribute__((uninitialized));

In the past, this has been suggested as an official way to suppress the
warning:

  char *buffer = buffer;

See <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296#c3> for an
example.

It has the downside that it is almost certainly not valid C++ and
probably not valid C, either.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

Re: __attribute__ to selectively disable -Wmaybe-uninitialized

[Segher Boessenkool]

On Sat, Oct 24, 2020 at 07:06:20PM +0200, Florian Weimer via Gcc-help wrote:
> * mark at yahoo via Gcc-help:
> 
> > The necessity to add many of these pragmas makes the code difficult to
> > read. Is there a variable attribute that could be used instead, 
> > something like:
> > char	*buffer __attribute__((uninitialized));
> 
> In the past, this has been suggested as an official way to suppress the
> warning:
> 
>   char *buffer = buffer;
> 
> See <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296#c3> for an
> example.
> 
> It has the downside that it is almost certainly not valid C++ and
> probably not valid C, either.

It isn't valid C, see 6.3.2.1/2, last sentence (accessing a var when it
is uninitialised, like the RHS of the assignment here does, is undefined
behaviour).  Yup.


Segher

Re: __attribute__ to selectively disable -Wmaybe-uninitialized

[Segher Boessenkool]

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

Re: __attribute__ to selectively disable -Wmaybe-uninitialized

[mark_at_yahoo]

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