[M3devel] warning for uninitialized variables?

[hendrik at topoi.pooq.com]

On Wed, Jun 02, 2010 at 02:52:55PM +0000, Jay K wrote:
> 
> Running with a consistent initialized/uninitialized 0 is better than running with a "random" value that you get from no initialization.
>  They are both "bad".
>  The 0 is agreed misleading, because it might look initialized.
>   But it still better than a value that can change from run to run.

Initializing it to cosistent gibberish won't look as initialized.  The 
University of Waterloo WATFOR compiler initialized all of memory to a 
consistent bit pattern that was *not* a printable character in the 
character set, and was *not* a valid exponent for a floating-point 
number.  It was a valid integer, though.  That much was OK, and would 
provide consistency with a high probability of misbehaviour on error.

But they went further and regularly checked for that value on reads.  It 
took time, it found errors, and it was a rare day that anyone needed 
that value.  But it did happen, and I consider the test a mistake for 
types that an validly assume all bit patterns.
> 
> Programs are written for humans to read, true, but programs that read programs are much more diligent, energetic, and often smarter (and slowly getting smarter with age, often the opposite of humans).
> Compilers really do have a big "leg" up on humans, since they can harness fast digital processor with big storage.
> Granted, neither is always better than the other. But compilers/computers have far more capacity for code reading than humans and I know from experience that most code is never read by a human, not even once, until I get to it :), because the bugs I readily see wouldn't survive even a glance...
>  (and the compilers often fail too, granted).
> 
> 
> Again I'm quite surprised we want to leave uninitialized variables 
> that get used uninitialized.  The one in cm3ide for example, if the 
> input is malformed, I believe it uses uninitialized data.
> I don't see how this can be deemed anything other than a bug to be 
> fixed, and that we should be glad the compiler (finally) found it..now 
> that I'm working on removing the rampant volatile...
> 
> 
> If we can invest in runtime checks to immediately catch reads of 
> unwritten data, then I'd favor that instead.

The hard part is distinguishing the truly uninitialized variable from a 
variable that pappens to validly get assigned a computed bit pattern 
that just happens to be the marker for "uninitialized".

But being able to turn on such a run-time check during debugging might 
make it wasier to find a *lot* of uninitialized variables, with only anb 
occasional false positive.

-- hendrik