Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!rehrauer
From: rehrauer@apollo.HP.COM (Steve Rehrauer)
Newsgroups: comp.sys.apollo
Subject: Re: The wonderful Pascal compilier...
Message-ID: <4e00f7c8.20b6d@apollo.HP.COM>
Date: 14 Nov 90 15:38:00 GMT
References: <43023@cci632.UUCP>
Sender: root@apollo.HP.COM
Reply-To: rehrauer@apollo.HP.COM (Steve Rehrauer)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 63

In article <43023@cci632.UUCP> mth@cci.com (Michael Hickman) writes:
>I have upgraded all of our machines to 10.3.  Last night a user tried running
>a program I had written that generates a cross reference list of nets on a PCB. 
>
>After the program ran all night (should have taken < 15 mins.) I killed it
>figuring it needed to be recompiled under 10.3.  The program compiled fine,
>but when I ran it, it barfed with an 'reference to illegal address (OS/MST 
>manager)' on this:
>
>    while not((this_net = nil) or 
>              ((this_net^.plusminus = net.plusminus) and
>               (this_net^.net_name  = net.net_name))) do
>
>Looks like it tried evaluating the expression after the 'or' when the pointer 
>was nil.  I changed it to this:
>
>    while ((this_net <> nil) and 
>       not((this_net^.plusminus = net.plusminus) and 
>           (this_net^.net_name  = net.net_name))) do
>
>It liked this, and the program ran.  However, another function that uses the EXACT
>same line as example #1 above works fine with no changes.  Compilier optimization
>level made no difference.
>
>It bothers me that it worked fine before, but doesn't now.  I'm certainly no programming
>guru, so if anyone can shed some light on this, please do.  Otherwise, this is just
>another example of Apollo's great compilier technology.....

Lord knows I'm no Pascal semantics guru.  However, your code looks a
bit bogus.  Pascal OR & AND boolean operators will evaluate both operands.
Even though your intent was clearly to say "If non-NIL pointer, then if...",
this isn't how your program will be interpreted by the compiler.  In many
circumstances, the compiler will be able to determine that evaluation of
the second operand is unnecessary, but you aren't guaranteed that behaviour.

Since you've upgraded to sr10.3, and presumably have an 8.7 Pascal compiler,
though, there is hope. :-)  Rather than standard OR & AND operators, you could
"OR ELSE" & "AND THEN", which *do* guarantee short-circuited evaluations.
For example, this Pascal snippet:

   IF ( ( ptr = NIL ) OR ELSE ( ptr^.intval <> 0 ) ) THEN

is intuitively the same as (but more compact to write than!):

   IF ( ptr <> NIL ) THEN
      IF ( ptr^.intval <> 0 ) THEN

Or, the example could've been written with "AND THEN", as:

   IF ( ( ptr <> NIL ) AND THEN ( ptr^.intval <> 0 ) ) THEN

If I were to attempt to rewrite your example snippet using "OR ELSE"
& "AND THEN", it'd probably come out looking like:

   WHILE ( ( this_net <> NIL ) AND THEN
           ( ( this_net^.plusminus = net.plusminus ) AND
             ( this_net^.net_name = net.net_name ) ) ) DO

Hope that helps.
--
"I feel lightheaded, Sam.  I think my      | (Steve) rehrauer@apollo.hp.com
 brain is out of air.  But it's kind of    | The Apollo Systems Division of
 a neat feeling..." -- Freelance Police    |       Hewlett-Packard