HP3000-L Archives

October 2001, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"TRAPP,RICH (Non-A-Loveland,ex1)" <[log in to unmask]>
Reply To:
TRAPP,RICH (Non-A-Loveland,ex1)
Date:
Tue, 30 Oct 2001 13:45:21 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (97 lines)
Stan,
  I've always used ;UNSAT="RESETCONTROL"...any issues with this?

RAT

   

Rich Trapp <mailto:[log in to unmask]>  

Consulting for Agilent Technologies, Loveland, Colorado.

Managed Business Solutions <http://www.mbsnav.com/>  
200 South College Avenue 
Fort Collins, Colorado 80524-2811 
970.679.2221 (voice) 
970.669.3071 (fax) 



-----Original Message-----
From: Stan Sieler [mailto:[log in to unmask]]
Sent: Tuesday, October 30, 2001 1:12 PM
To: [log in to unmask]
Subject: Re: Unresolved externals


Re:
> Modify the program file with with LINKEDIT to set the UNRESOLVED=
> option within the program. Here is a quick solution: set the
> program to UNRESOLVED=DEBUG, or TERMINATE or even TIMER. You

Never use "=TIMER"!  Always use something that won't hurt you,
like "=QUIT", "=TERMINATE", or (if you're really sure you
want to) =DEBUG.

Why?

Let's assume you have a program with an unresolved external
named "foo" ... which you're *SURE* never gets called.

If you link (or run) with UNRESOLVED=TIMER, and then the
unexpected ... the *absolutely impossible, insanely unlikely* thing
happens: "foo" is called.

In this case, TIMER will be called instead, and it will return with
some number in R28.

Now, let's speculate on what "foo" was supposed to do.
Let's say it was supposed to return the number of bytes in a file
that should be zeroed out.  Uh oh.
Or, let's say the programmer thought foo should return a data address,
one which is going to get a 0 stored into it.  Uh oh.

The results can range from nothing, to simple program aborts, to
system failures, to lawsuits, to death (e.g., software controlling
medial equipment in a hospital).

In short, *NEVER* use "UNRESOLVED=xxx" where "xxx" can possibly
cause any kind of problem.

In fact, we should lobby HP to provide a new intrinsic:

    procedure MISSING;

Then, we could link (or run) with UNRESOLVED=MISSING
and, when called, MISSING would always do:

    - report something like:
         the program attempted to call "foo",
         which is an unresolved procedure.
         The program is now terminating.

    - produce a stacktrace;

    - unconditionally terminate.

This "MISSING" intrinsic would allow people the safety of
using UNRESOLVED to get their program loaded and running, and
would provide extremely valuable information if it actually
got called: the fact that it was called, and the name of the
routine that called it.

I can count the number of times that I've done "UNRESOLVED=xxx"
where xxx *wasn't* DEBUG/TERMINATE/QUIT on the thumbs of my left foot.


Ok...I submitted an enhancement request, Call ID 3200410300.

Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2