Re: [ooc-compiler] Is this allowed?

[Michael v. A. <mi...@de...>]

Stewart Greenhill <sgr...@ip...> writes:

> Hi Folks,
> 
> I got some surprising behaviour from OOC. I'm not sure whether this is a bug
> or not.
> 
> [Example removed...]
> 
> In the code produced by OOC, the dereference of obj is checked before the
> call to Check so the program generates a NIL dereference instead of
> terminating in a controlled way.
> 
> [...]
> 
> Is the original transformation legitimate? To me, it seems that checking the
> dereference first is disallowing a "side effect" of Check which is the
> orderly termination of the program.

This is indeed a bug.  The transformation is only valid if the
compiler could prove that `Check()' has no side-effects and does not
cause a program exit (e.g., due to a run-time error) itself.  Almost
no procedure matches this criteria, so this transformation is almost
always wrong :-(

This is an underlying problem of OOC1, which is a little bit vague on
the semantics of traps, program termination, endless loops and the
guarantees attached to these events.  The basic idea is that
regardless of the transformations applied, the program must always
terminate with the same run-time error (or program exit), and always
produce the same program output.  Obviously, this doesn't happen here.

Solving this problem the Right Way(TM) would require considerable
effort, which I don't want to sink into OOC1.  I remember that I was
forced to revert to the "IF Check() THEN ... END" workaround some time
back myself.  Hey, I thought, it's even more readable that way ;-)

-- mva