Bug 42884 - GCC (v4.3.3) fails to detect uninitialized variable
Summary: GCC (v4.3.3) fails to detect uninitialized variable
Status: RESOLVED DUPLICATE of bug 18501
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2010-01-27 13:58 UTC by Tom St Denis
Modified: 2010-09-03 14:06 UTC (History)
19 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.3.3 4.4.0 4.5.0
Last reconfirmed: 2010-01-27 14:07:08


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom St Denis 2010-01-27 13:58:43 UTC
GCC fails to detect an unitialized variable in a function.  In the attached code [warning.c] it fails to detect that 'diglen' could be unitialized by time the 'for' loop is encountered.
Comment 1 Paolo Carlini 2010-01-27 14:00:55 UTC
No attachment. Moreover, please try also a more recent release, in the 4.4.x series.
Comment 2 Tom St Denis 2010-01-27 14:01:27 UTC
Here's the file [I'm getting an internal error when submitting a file]

---warning.c---
#define NULL ((void *)0)
#define OK 0

typedef struct { void *a; } state;

int init(int, state *);
int done(unsigned char *, unsigned long *, state *);

int function(unsigned char *param5, unsigned long   param6)
{
   state st;
   unsigned char dig[128];
   unsigned long y, outpos, diglen;
   int           err;

   outpos = 0;
   err    = OK;
   while (err == OK && outpos < param6) {
      err = init(0, &st);
      if (err == OK) {
         diglen = sizeof(dig);
         err = done(dig, &diglen, &st);
      }
      for (y = 0; y < diglen && outpos < param6; y++) {
          param5[outpos++] = dig[y];
      }
   }
   return err; 
}
Comment 3 Tom St Denis 2010-01-27 14:02:50 UTC
(In reply to comment #1)
> No attachment. Moreover, please try also a more recent release, in the 4.4.x
> series.
> 

No warning from GCC 4.4.0 when using '-Wall -W -O3'.
Comment 4 Paolo Carlini 2010-01-27 14:07:00 UTC
Yes. I'm pretty sure we have duplicates in Bugzilla. Anyway, I just tested two other high quality compilers and they don't warn either. I don't think we can reach zero negatives in this area any time soon.
Comment 5 Tom St Denis 2010-01-27 14:08:52 UTC
(In reply to comment #4)
> Yes. I'm pretty sure we have duplicates in Bugzilla. Anyway, I just tested two
> other high quality compilers and they don't warn either. I don't think we can
> reach zero negatives in this area any time soon.
> 

If this bug is a dupe please close this as resolved/dupe.  I didn't check that hard.

I think this is a bug because GCC attempts to resolve whether variables are initialized or not and doesn't in this case.  It's misleading to the user to suggest it can do something it clearly cannot [in this case].
Comment 6 Paolo Carlini 2010-01-27 14:13:22 UTC
I'm restating my point: indeed, the variable can be used uninitialized. This is not at issue. My point is that, depending on the way the compiler is internally organized, etc, you can have it warning for a larger class of cases and not warning for a larger class of non-cases, but normally you cannot obtain full accuracy. As two data points, for comparison, I told you that two other, up to date, high quality, compilers don't warn either. I'm saying, do not hold your breath on this, in principle we can, and should, make progress, but it's hard to say now how much and when.
Comment 7 Tom St Denis 2010-01-27 14:28:03 UTC
(In reply to comment #6)
> I'm restating my point: indeed, the variable can be used uninitialized. This is
> not at issue. My point is that, depending on the way the compiler is internally
> organized, etc, you can have it warning for a larger class of cases and not
> warning for a larger class of non-cases, but normally you cannot obtain full
> accuracy. As two data points, for comparison, I told you that two other, up to
> date, high quality, compilers don't warn either. I'm saying, do not hold your
> breath on this, in principle we can, and should, make progress, but it's hard
> to say now how much and when.


I take your point about false warnings, but if something like coverity can correctly identify this, it is possible.  I wouldn't expect this to be fixed overnight, but part of the point is to at least report these things so developers know about them.
Comment 8 Paolo Carlini 2010-01-27 14:37:05 UTC
Is 'coverity' a compiler? I don't think so. Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning?
Comment 9 Tom St Denis 2010-01-27 15:43:07 UTC
(In reply to comment #8)
> Is 'coverity' a compiler? I don't think so. Do you have actual examples of
> *compilers* which, everything taken into account, decided to make sure this
> case is worth warning?

I wonder if there is an "apathy" reason to close bugs.... ho hum...

I'm just saying that it is something that should at some point be addressed.  Maybe not today, maybe not tomorrow, but soon, and for the rest of the projects life cycle.
Comment 10 Paolo Carlini 2010-01-27 15:47:21 UTC
To be clear: nobody closed this bug, ever. And talking about apathy is plain offensive, or maybe you are just ignorant of the trade-offs involved in this area.
Comment 11 Tom St Denis 2010-01-27 15:57:58 UTC
(In reply to comment #10)
> To be clear: nobody closed this bug, ever. And talking about apathy is plain
> offensive, or maybe you are just ignorant of the trade-offs involved in this
> area.

I didn't say you did close the bug I said you probably should if everyone is apathetic as you appear to be.

I don't care if commercial compilers miss this, GCC claims to detect this sort of bug, it doesn't, that's a bug.  Furthermore, it is detectable in an automated way [e.g., coverity] so it's not like I'm asking to boil the ocean or whatever... Whether it's high priority or not [I don't think it is] is not at issue.  So stop being so dismissive about it.
Comment 12 Paolo Carlini 2010-01-27 15:59:24 UTC
You are apathetic, and your mother and son.
Comment 13 Tom St Denis 2010-01-27 16:05:30 UTC
(In reply to comment #12)
> You are apathetic, and your mother and son.
>`

Apathy: noun, a lack of enthusiasm or emotion.

Being dismissive of the bug because other compilers don't detect it either is apathetic.

Irony: noun, A statement that, when taken in context, may actually mean the opposite of what is written literally; the use of words expressing something other than their literal intention, notably as a form of humor.

Calling someone who took the time to file a bug report apathetic is ironic.
Comment 14 Richard Biener 2010-01-27 16:06:10 UTC
As diglen has its address taken and we do not warn about uninitialized use
of memory we do not warn.
Comment 15 Tom St Denis 2010-01-27 16:22:22 UTC
(In reply to comment #14)
> As diglen has its address taken and we do not warn about uninitialized use
> of memory we do not warn.
> 

I get that the compiler can't track if an external function actually initializes a value through a pointer, but the "diglen = sizeof..." line should be good enough for the positive case.  In the false path though "diglen" is not initialized nor its address taken.
Comment 16 Richard Biener 2010-01-27 16:51:07 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > As diglen has its address taken and we do not warn about uninitialized use
> > of memory we do not warn.
> > 
> 
> I get that the compiler can't track if an external function actually
> initializes a value through a pointer, but the "diglen = sizeof..." line should
> be good enough for the positive case.  In the false path though "diglen" is not
> initialized nor its address taken.

No, it's an implementation detail.  Uninitialized variable use tracking
works with detecting uses of SSA name default definitions.  Memory 
is not in SSA form so this mechanism does not work.

Uninitialized memory detection is not done at all.
Comment 17 Tom St Denis 2010-01-27 17:55:26 UTC
(In reply to comment #16)
> No, it's an implementation detail.  Uninitialized variable use tracking
> works with detecting uses of SSA name default definitions.  Memory 
> is not in SSA form so this mechanism does not work.
> 
> Uninitialized memory detection is not done at all.
> 

Forgive me for I know not much of the GCC internals (I use GCC, I don't develop it), but are you saying that any use of address-of on a variable kicks it out of contention for unused tracking?  Even if it's not on a direct path (e.g., not always executed)?
Comment 18 Richard Biener 2010-01-27 19:51:39 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > No, it's an implementation detail.  Uninitialized variable use tracking
> > works with detecting uses of SSA name default definitions.  Memory 
> > is not in SSA form so this mechanism does not work.
> > 
> > Uninitialized memory detection is not done at all.
> > 
> 
> Forgive me for I know not much of the GCC internals (I use GCC, I don't develop
> it), but are you saying that any use of address-of on a variable kicks it out
> of contention for unused tracking?  Even if it's not on a direct path (e.g.,
> not always executed)?

Yes, that's correct.
Comment 19 Tad Hunt 2010-09-02 16:01:07 UTC
This flamewar in the comments is hilarious.

To all concerned, here is a much simpler example.  This does appear to be a regression.  I apologize that I cannot help fix it, as it's a really useful feature that helps catch bugs.  Hat's off to you folks working hard on gcc.

int
main(void)
{
        int len, i;

        for(i = 0; i < 5; i++) {
                printf("%d\n", len);            // no warning!
                len = 10;
        }

        return 0;
}
Comment 20 Manuel López-Ibáñez 2010-09-02 23:10:03 UTC
The first testcase and the second are different issues. Both of them are old, known and reported in bugzilla. None of them are trivial to fix. 

GCC developers would wish to make our compiler as powerful as to solve the halting problem in less than a blink. Unfortunately, time, money, and contributors willing to work on this particular problem are scarce. If you can help in some way, please do so. Otherwise, thanks for the report anyway.

*** This bug has been marked as a duplicate of 18501 ***
Comment 21 thutt 2010-09-03 13:07:47 UTC
(In reply to comment #8)
> Is 'coverity' a compiler? I don't think so.
> 

Coverity is not a tool that generates code, but it does perform
all the syntactic & semantic analysis that a code-generating compiler will.
Then, it goes beyond that with further static analysis.

> Do you have actual examples of
> *compilers* which, everything taken into account, decided to make sure this
> case is worth warning?

That's the worst argument I've read in a long time.
Do we need proof that another compiler does something before the gcc 
team will take it up now?
Comment 22 Manuel López-Ibáñez 2010-09-03 14:06:30 UTC
(In reply to comment #21)
> (In reply to comment #8)
> > Is 'coverity' a compiler? I don't think so.
> > 
> 
> Coverity is not a tool that generates code, but it does perform
> all the syntactic & semantic analysis that a code-generating compiler will.
> Then, it goes beyond that with further static analysis.

GCC is not designed to be used as a static analysis tool. This doesn't mean it wouldn't be interesting to be able to reuse GCC analysis modules for doing that. Other compilers have shown that it is possible and a desirable feature [*]. However, GCC is not designed to be reusable, there is none working on a similar thing for GCC, and no sign that any existing GCC developer will start working on it in the near future. Unless someone new starts working on this, don't expect anything similar from GCC.

[*] http://clang-analyzer.llvm.org/

> > Do you have actual examples of
> > *compilers* which, everything taken into account, decided to make sure this
> > case is worth warning?
> 
> That's the worst argument I've read in a long time.
> Do we need proof that another compiler does something before the gcc 
> team will take it up now?

There is more work to do in GCC than people willing (or being paid) to do it, so if there is some indication that some feature may be impossible or too expensive to implement, existing GCC developers will probably focus their efforts on something else more feasible. If you can show that another compiler is able to do it in an efficient way, that shows that it is feasible. As far as I know, GCC has always been a very conservative compiler in terms of features, not a source of innovation. So yes, showing a working implementation seems to be a necessary condition (but not a sufficient one).

In fact, it is common practice to check what other compilers do in order to verify a bug, and it is useful information in bug reports.

I am sorry for this flamewar. I hope I clarified all the issues and the wiki [**] contains a more detailed discussion about the technical issues related to uninitialized warnings in case anyone is willing to help to solve them.

[**] http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings