[M3devel] warning for uninitialized variables?

[hendrik at topoi.pooq.com]

On Wed, Jun 02, 2010 at 04:50:28AM +0000, Jay K wrote:
> 
> Wow. You really surprise me Mika.
> 
> 
> To warn on this kind of thing, to me, there is no question.
> 
> 
> Limting the affects by virtue of being safe isn't much consolation.
> The program can easily go down a "safe" but very incorrect path.
> 
> 
> There are several forms.
> In fact, sometimes the compiler says something "is" used uninitialized.
> Sometimes it says "maybe".
> 
> 
> In your example, generally, once the address is taken of a variable,
> the compiler gives up. Esp. if that address is passed to a function it doesn't "see".
> 
> 
> However compilers are getting better.
> Windows headers are now annotated with "in" and "out", etc. with
> a calculus behind them, not just informal human definitions.
> 
> 
> So if you pass something by pointer to "in" you should a warning/error.
> If it is "out", ok.
> 
> 
> The annotations can even be checked, if you write to something that is "in"
> you should get a warning/error.
> 
> 
> There are many more warnings in the tree than I have yet looked at.
> I've seen a few forms.
> Some are because the compiler doesn't know that some functions don't return.
> I'll see about improving that. Though I think there's a limit to how good I can manage,
> unless we add a <* noreturn *> pragma.

Or a new type that has *no* values at all, and therefore can never be 
returned by anything.  If it'e the type of an expression, that 
expression can never return a value.

Notice, that if you were to let statements have a type (Algol 68 does, 
calling it the VOID type) that type would *not* be the type with no 
values at all.  The VOID type has one value, and needs log(1) = 0 bits 
to store it.

The NORETURN type would have no values, is never stored.  log(0) doesn't 
give a meaningful numper of bits, which is right.

> 
> I grant that by initializing to 0, I haven't necessarily made the code correct either.
> But at least it is now consistent.

It's very useful for code execution to ne repeatable.

> 
> 
> Even better would be runtime checks that stop if a variable is read 
> before written.

Takes extra storage, unless there are bit patterns that are known to fit 
in the available space *and* be invalid values for the type.

> 
> 
> Uninitialized values can be different run to run.
> Repeatability and consistency are important.

*VERY*

> I'm also nervous about us not taking a hard line on integer overflow.
> Overflown math doesn't necessarily lead to array out of bounds soon or ever.
> It too can lead to incorrect but safe behavior.

I agree.  But I do need a way to turn it off for specific operations so 
I get modulo results.  Perhaps also a specific type for wrap-around 
arithmetic?

-- hendrik