[M3devel] warning for uninitialized variables?

[Jay K]

Search the web for "visual C++ /rtc".
 
You'll find that Visual C++ has the ideal feature here, not enabled by default. Not efficient.
 
If you compile with /RTCu:
  an extra byte local is created for each local variable 
  It is initialized to zero.
  Writes to the variable write 1 to the extra. (taking the address does to, the documentation spends a lot of space explaining) 
  Reads of the variable check if the extra is 0 or not and if it 0 a function is called to report the error.
 
 
It's pretty cool imho.
 
 
And it appears if the compiler can prove the variable isn't initialized, the checking is omitted.
Given decent code, that should make it very affordable to always be enabled.
 
 
 - Jay


----------------------------------------
> Date: Thu, 3 Jun 2010 19:51:03 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> 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