Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Critical error handler
Message-ID: <1521@atari.UUCP>
Date: 2 Jun 89 18:50:26 GMT
References: <26@meadow.UUCP> <757@sbsvax.UUCP>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 27

In article <757@sbsvax.UUCP> roeder@sbsvax.UUCP (Edgar Roeder) writes:
> You can install a normal C-routine as the error handler. But you can only
> call Bios-functions for terminal output, since the handler may be called
> from a GEMDOS-function and since GEMDOS is not reentrant (*), you can't use
> GEMDOS-functions like Cconout() (and most printf()'s in C-Compilers).
>
> (*) GEMDOS is not reentrant when called by the Bios because it uses a static
> (and undocumented (!)) storage location for the return address when it calls
> a Bios-function like for example Rwabs() from inside Fwrite() which
> eventually calls the critical error handler.

Give me a break! GEMDOS is not reentrant for more reasons than that! And
you don't expect us to document EVERY VARIABLE that GEMDOS uses, do you?

GEMDOS is not reentrant because (A) it sets SSP to the same address
every time it's called, and (B) it uses the basepage of the current
process to store the context (the registers, incl.  PC).  If you make a
GEMDOS call from within a GEMDOS call, the second one overwrites the
stack of the first one and overwrites the first caller's context.  NOw
that's what *I* call non-reentrant!

Given those two reasons, finding other reasons for non-reentrancy in
GEMDOS is little more than vanity or folly. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt