[M3devel] warning for uninitialized variables?

[Jay K]

I've looked but can't quite find the paper. I found its "number".
Modula-3 ... I think beats C, because I can specify initializers for records, and subranges and enums are initialized.
C++ is more general and nice though since I can specificy initialization functions for types. Not as unenforced convention as in Modula-3, but enforced because the compiler makes the calls. Though Modula-3 does at least have the compiler generally do some initialization.


"what to do about it", well, compilers these days can tell us.
I/we have to go through the warnings that my upcoming change generate. A fair number.
But I/we should wait until I also have fault_proc marked as "noreturn", since that should help reduce them.
And maybe maybe even add <* noreturn *> pragma or such, since I know there cases like:
  (possibly the front end figures it out by seeing what you call, but still need to communicate it down)


if x = 0
  i = 0
else if x = 1
  i = 2
else if x = 2
  i = 4
else
  error(); (* probably noreturn *)
print i (* compiler complains it might be uninitialized, from the error case *)


 - Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Wed, 2 Jun 2010 08:32:20 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> Jay K writes:
>>
>>Well=2C I'm certainly not lobbying hard for that=2C presumably there is no =
>>efficient implementation=2C esp. for full range integers.
>>
>>Wikipedia has a nice article. "nice" means "agrees with me".
>>
>>
>>http://en.wikipedia.org/wiki/Uninitialized_variable
>>"it is a programming error and a common source of bugs in software."
>
> I don't think anyone disagrees too strongly with that, Jay, but
> the question is what can be done about it. I think the sad answer
> is, "not much."
>
>>
>>
>>And then they point out how Java requires mechanically verified initializat=
>>ion of locals.
>
> One might equally well say that an infinite loop is a programming error
> and a common source of bugs in software.
>
> Some good people, accordingly, insist that every loop be accompanied by
> a proof of termination.
>
> The difference is, of course, that it is obvious that there are
> useful loops that we cannot ever expect a compiler to be able to prove
> termination of (on its own), whereas "some people feel" that there are
> no useful ways of initializing variables that could not be verified
> correct by a particular implementation of the Java compiler.
>
> I think that if you take a step back from the problems you will see
> they are in fact the same problem: they both breach the "undecidability
> barrier". This is because we haven't put enough information in the
> variable declarations themselves to deduce what is wanted. EWD's chapter
> is a start on that---how to do this statically. (That's the last time
> I'm going to plug that chapter, I promise.)
>
> Modula-3 actually has some very nice mechanisms for avoiding uninitialized
> variables. The ability to declare/initialize a variable from an
> expression without providing an explicit type is one. WITH is another.
> I almost never have problems with uninitialized variables in my Modula-3
> programs. Almost...
>
> Mika