Maurice Lombardi wrote:
Adriaan van Os a écrit:
Any comment on http://www.freepascal.org/mantis/view.php?id=9053 and Daniël Mantione's note ?
I would have guessed that it would compile (maybe with a warning) with the compilation option --no-iso-goto-restrictions
It does -- with a warning, as you say. (The option is called --no-iso-gotos.)
Gale Paeper wrote:
In regards to Daniël Mantione's note:
"Allthough GPC handles it more nicely, I'd say both compilers are in error; since the exit statement is reachable via the goto, the compiler is not allowed to optimize the if-statement away."
Daniël is mistaken that the exit statement is reachable via the goto in a legal ISO Pascal program. The label prefixing statement "10: Exit" does not satisfy any of the goto statement containing requirements of ISO 10206, paragraph 6.9.1 general requirements for labels and goto statements:
It appears that Daniël is also erroneously assuming the reason for GPC's error message is because the if statement was optimized away. That isn't the reason for GPC's error message. The reason is because the label "10" isn't permitted to occur in the goto statement per ISO requirements.
Since FPC makes no claims for ISO Pascal requirements compliance, the FPC compiler may not enforce ISO label and goto statement requirements so what is or isn't legal with FPC depends upon what the FPC compiler folks have defined the requirements to be. As a general observation I'll note that transferring control into a nested statement can result in ill program behavior which is why ISO PAscal prohibits it.
I agree.
In strict ISO, the code is indeed unreachable. Letting the assembler detect the invalid goto, while not strictly incorrect in this case, might be confusing. (And it won't work for invalid gotos in most other cases.)
OTOH, if you do allow such gotos (which are indeed problematic in some cases, and at least on the verge in this case), like GPC does with "--no-iso-gotos", and I think BP does generally, and apparently also FPC does by default, then of course, you cannot optimize away code which, due to a label, is not in fact unreachable.
Frank