[EMAIL PROTECTED] (Robert Dewar) wrote on 18.06.05 in <[EMAIL PROTECTED]>:
> Here is an interesting example I have used sometimes to indicate just > how this kind of information can propagate in a manner that would result > in unexpected chaos. (Ada but obvious analogies in other languages) > > > -- process command to delete system disk, check password first > > loop > read (password) > if password = expected_password then > delete_system_disk; > else > complain_about_bad_password; > npassword_attempts := npassword_attempts + 1; > if npassword_attempts = 4 then > abort_execution; > end if; > end if; > end loop; > > Now suppose that npassword_attempt is not initialized, and we are in a > language where doing an operation on an uninitialized value is undefined, > erroneous or whatever other term is used for undefined disaster. > > Now the compiler can assume that npassword_attempts is not referenced, > therefore it can assume that the if check on password is true, therefore > it can omit the password check AARGH! > > This kind of backward propagation of undefinedness is indeed worrisome, > but it is quite difficult to create a formal definition of undefined > that prevents it. But at least, in that case, the compiler could easily issue the (presumably not required by the standard) warning that the else branch is "unreachable code". 1/2 :-) MfG Kai
