[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

Reply via email to