--- 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@xxxxxxxxxxx> 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@xxxxxxxxx
>
>
>
