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.
Posted Dec 20, 2012 14:18 UTC (Thu) by clugstj (subscriber, #4020)
[Link]
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()
Posted Dec 21, 2012 5:29 UTC (Fri) by nevets (subscriber, #11875)
[Link]
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.