LWN: Comments on "Removing uninitialized_var()"

Removing uninitialized_var()

oak — Sun, 13 Jan 2013 00:39:54 +0000

GCC not detecting all the cases where variable might be uninitialized (and it requiring optimizations enabled to find what it can find) is one thing, but it's not what annoys people. Wrong warnings are what annoy them.

As noted, GCC does these checks using information gathered with the optimization passes. A bug in GCC 4.5 and earlier was that it did the warning before all optimization passes had been done and therefore could give warnings for code paths that weren't relevant (= dead, would never happen). This was (at least mostly) fixed in GCC 4.6 and there is/are bugs about it in the GCC bugzilla.

Even if kernel people wouldn't fix GCC bugs instead of kludging kernel code, at least they could file bugs against GCC, or if there's already a bug on the issue, add a pointer to it and comment in code about which GCC version fixes that bug.

(On quick glance of these kind of bugs in GCC bug tracker, most of them seem to be pretty old and might be already fixed with GCC 4.6, I think they need a bit of a re-testing & cleanup.)

Removing uninitialized_var()

nix — Fri, 04 Jan 2013 23:24:55 +0000

It's impossible to get it right *in the general case*. You can get it right in an arbitrarily large percentage of special cases (and indeed, GCC often does, when it says 'is used uninitialized' rather than 'may be used uninitialized').

Removing uninitialized_var()

heijo — Fri, 04 Jan 2013 12:05:31 +0000

It's impossible (http://en.wikipedia.org/wiki/Rice_theorem).

Removing uninitialized_var()

mlopezibanez — Fri, 04 Jan 2013 10:16:54 +0000

There is indeed a limit to what GCC can guess correctly, but there are also quite a number of bugs and deficiencies in the warning machinery. See http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings for a list of problems (the page may be slightly outdated by now) and http://gcc.gnu.org/PR24639 Solving these problems would require substantial work. Unfortunately, there is no enough people working on GCC to even start such work in the near future.

I wonder if kernel devs would be less frustrated with gcc if they tried to fix GCC bugs rather than work-around them. Well, perhaps they will become even more frustrated. ;-)

Removing uninitialized_var()

stevenb — Fri, 28 Dec 2012 20:38:40 +0000

That case is handled just fine, at least AFAICT:

$ cat t.c
extern int foo_p (int *, int);
extern int foo (int, int);
extern void bar (void);

int foo_p (int *x, int y)
{
int a;
if (*x) a = y;
bar ();
if (*x) return a;
bar ();
return -1;
}

int foo (int x, int y)
{
int a;
if (x) a = y;
bar ();
if (x) return a;
bar ();
return -1;
}
$
$ gcc-4.4 -S -O2 -W -Wall -Wextra t.c
t.c: In function ‘foo_p’:
t.c:7: warning: ‘a’ may be used uninitialized in this function
$
$ gcc-4.6 -S -O2 -W -Wall -Wextra t.c
t.c: In function ‘foo_p’:
t.c:7:7: warning: ‘a’ may be used uninitialized in this function [-Wuninitialized]
$
$ ./xgcc -B. -S -O2 -W -Wall -Wextra t.c --version
xgcc (GCC) 4.8.0 20121226 (experimental) [trunk revision 194725]
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ./xgcc -B. -S -O2 -W -Wall -Wextra t.c
t.c: In function 'foo_p':
t.c:7:7: warning: 'a' may be used uninitialized in this function [-Wmaybe-uninitialized]
int a;
^
$

In foo_p, the compiler cannot know whether bar will change the value at *x and the warning is valid. In foo, which is your example, there is no warning. In general, there will be no warning if the compiler can prove that the code in your "/* later */" doesn't change the result of the tested conditional. This is implemented in tree-ssa-uninit.c.

Still, it's true that there will be false positives, or missed warnings. Proving whether a variable is used uninitialized is not an easy problem.

Removing uninitialized_var()

apoelstra — Fri, 21 Dec 2012 23:13:30 +0000

> My point is that, as easy as it is to confuse gcc or clang, confusong the programmer who has to read the code after you is even easier!

This is not always true. For a small-enough function (or small-enough block), a programmer can probably build a mental parse tree just as well as the compiler can -- and then, because he is a human gifted with all manner of high-level knowledge and context, he can easily see things that the compiler might miss.

And in my experience, "small enough" includes many non-trivial functions of 5-10 lines. Also in my experience, these are the sorts of functions that trigger uninitialized variable warnings.

Removing uninitialized_var()

hummassa — Fri, 21 Dec 2012 21:22:27 +0000

My point is that, as easy as it is to confuse gcc or clang, confusong the programmer who has to read the code after you is even easier! Let is substitute your question #2 for "did you ever have had eclampsia?" And now the comparison is fair. 50 percent of male respondents will not know what it is and many will answer wrongly.

Removing uninitialized_var()

giraffedata — Fri, 21 Dec 2012 20:14:35 +0000

As the article points out, it's amazingly easy to confuse the compiler. In the cases where I've had to deal with this, there was clearly no practical alternative way to write the code. The only practical ways to shut the compiler up were to give a variable a fake value or disable the warning class.

I do agree that code with variables that are sometimes meaningless is harder to read than code without. I don't agree that when such meaningless variables exist, the code is equally hard to read when you assign values to them.

Here's the analogy: You're filling in an online medical history form. Question 1: sex. Question 2: if female, when was your last menstruation? No doctor will be the least bit concerned when he sees a man leave Question 2 blank. He might be confused if he sees a date in there for a man. In fact, he would be well justified in thinking Question 1 might be an error in that case. GCC is the automatic field checker that notices Question 2 is blank and makes the man put a date in there before it will accept the form, because it isn't smart enough to know what menstruation is and simply insists that every field be filled in, to avoid accidental omissions.

Removing uninitialized_var()

bronson — Fri, 21 Dec 2012 17:58:07 +0000

Yes, well said! That's worth hanging on the wall.

Removing uninitialized_var()

hummassa — Fri, 21 Dec 2012 09:02:40 +0000

My response was going to be similar; "if you managed to confuse the compiler, you lost your human readers a long time ago."

Removing uninitialized_var()

dvdeug — Fri, 21 Dec 2012 05:32:57 +0000

Anytime this comes up, the code is hard to read. Variables that don't have valid values in chunks of code are problematic, and GCC wouldn't issue this error in a case where there's no branching or other stuff to confuse the issue. If you can't rearrange it so that it's clear to GCC that it's set before used, whether you initialize it isn't going to make it significantly more unclear to readers.

Removing uninitialized_var()

nevets — Fri, 21 Dec 2012 05:29:28 +0000

No, NULL may be better than uninitialized_var(), but it is not better than hiding gcc from warning about it.

Yes, a NULL pointer is easy to debug after a crash, but if it requires a tight race to get to a point where NULL will crash, that means you wont detect the bug until the crash happens. If that crash happens while on a production system, it's still a major issue.

My point is that uninitialized_var() isn't very good because it may hide bugs, but so is blindly initializing something, even with NULL. It's still hiding a bug.

Removing uninitialized_var()

giraffedata — Fri, 21 Dec 2012 02:22:47 +0000

The reason I don't initialize a variable to avoid the false positive warning is that it makes the code harder to read. It suggests that the variable's value is meaningful in places where it isn't. That requires more time and short term memory for the reader to understand the code.

I just disable the warning (by compiler option). I do appreciate it finding my used-before-set variables, but it isn't worth the false positives or dirtying of the code.

Removing uninitialized_var()

zlynx — Thu, 20 Dec 2012 19:38:27 +0000

I recently read something discussing common threading pitfalls and code similar to yours came up.

It is kind of amazing how many non-intuitive optimizations can be made on code like that.

For example, it might be rewritten to something like:

initialize a
do stuff
use a
if (!foo)
undo using a

or rewritten into two function blocks, one for if (foo) and one for if (!foo).

or the initialization of a might be moved down into the other if (foo) block.

So anyway, it is entirely possible that after GCC swizzles the code around it cannot tell anymore. It might have actually used a without even looking at foo, intending to undo it later.

Removing uninitialized_var()

nix — Thu, 20 Dec 2012 15:03:10 +0000

It can, of course, never be right in all circumstances (that would require a solution to the halting problem). It can sometimes be sure, and says as much ('is used uninitialized'). Often, it's not sure. What's odious is that there are lots of apparently simple cases that GCC can't yet handle, e.g.

if (foo)
/* initialize a */

/* later */

if (foo) /* value not affected by code above */
/* use a */

is a particularly notorious case.

Removing uninitialized_var()

kpfleming — Thu, 20 Dec 2012 14:48:52 +0000

The primarily complication is that developers (and users) use widely varying versions of GCC. Over time, of course, GCC gets better and better at avoiding false warnings, and developers tend to use the latest-and-greatest version on their systems. Users, though, like to stick with long-term-support distributions that have older compiler versions (some still using GCC 4.3.x), but also want their software to build without warnings. When the user reports a bug about a compiler warning, the developer frequently responds that it doesn't happen with the latest GCC, and wants to close it.

Solving the user's problem ends up requiring ugly workarounds that change the code (typically in non-functional ways) just to silence compiler warnings. Given that, it's quite reasonable to classify a compiler warning that is generated from code that cannot be trusted to have exhaustive proof of the potential failure as a 'bug' in the compiler.

Removing uninitialized_var()

clugstj — Thu, 20 Dec 2012 14:18:07 +0000

NULL is better than "anything else". The reason to set a variable to a consistent invalid value is that then the code fails consistently. Consistent bugs are much easier to track down.

Removing uninitialized_var()

mjthayer — Thu, 20 Dec 2012 12:11:28 +0000

I wonder whether it is quite fair to the gcc people to call this a "compiler [bug] (*stupid* gcc behavior)"? Not that I know very much about compiler internals, but instinctively I wouldn't expect getting this sort of warning right to be an entirely trivial task.

Removing uninitialized_var()

error27 — Thu, 20 Dec 2012 06:50:32 +0000

I've always thought uninitialize_var() macro was a bit ugly to look at.

The problem with setting pointers to NULL is that it silences the GCC warning, but it now triggers a "dereferencing NULL" warning in Smatch. Uninitialize_var() solved this problem nicely. I wish there were some macro that Smatch could understand.

struct foo *p = SILENCE_GCC;

Removing uninitialized_var()

nevets — Thu, 20 Dec 2012 02:47:12 +0000

I remember when uninitialized_var() was introduced. I actually liked the idea. IIRC, the idea was you could turn it off in one place and recheck all the locations that it was used. Even though I liked it, I always avoided using it. I rather be reminded of things that may be uninitialized.

My experience was that, depending on which version of gcc you used, it may or may not complain about a possible uninitialized var. I had some code that gcc 4.6+ had no issue with, but 4.5.x did. I would constantly get a patch to initialize the variable (a pointer) to NULL. I refused each patch simply because 4.6 didn't complain, and more importantly, if the variable was used outside of the expected path, a NULL pointer would crash it. If I later changed the code where the variable was used without the proper initialization, the NULL was no better than anything else, and it would hide the bug just as much as uninitialized_var() would.

I'm a bit weary of default initialization. You need to look at the code to determine if what you initialized the variable to is any better than it being random.