[EMAIL PROTECTED] (Robert Dewar)  wrote on 19.06.05 in <[EMAIL PROTECTED]>:

> Kai Henningsen wrote:
>
> > 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".
>
> Yes, absolutely, a compiler should generate warnings as much as possible
> when it is making these kind of assujmptions. Sometimes this is difficult
> though, because the unexpected actions emerge from the depths of complex
> optimization algorithms that don't easily link back what they are doing to
> the source code.

Actually, the reason I named an unrechable code warning was on the  
presumption that the compiler would not necessarily realize the problem,  
but a part of the compilers reasoning would necessarily make that into  
unreachable code and thus could trigger the generic unreachable code  
warning completely independent of why that code is determined to be  
unreachable.

And of course, that's only applicable to that specific case.

> Actually an easier warning here is that npassword_attempts is uninitialized.
> That should be easy enough to generate (certainly GNAT would generate that
> warning in this situation).
>
> Working hard to generate good warnings is an important part of the compiler
> writers job, even if it is quite outside the scope of the formal standard.
> Being careful to look at warnings and not ignore them is an important part
> of the programmers job :-)

In this context, also see the warning controls project. I'm very, very  
happy that things are finally moving on that front.

MfG Kai

Reply via email to