Trapping I/O runtime errors in GPC_(re)

Mon, 27 Oct 1997 08:50:16 GMT

Bill Currie wrote:

> On 23 Oct 97 at 10:43, Peter Gerwinski wrote:
> 
> > According to Jesper Lund:
> > > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-}
> > > compiler directive in Borland Pascal? [...]
> > 
> > Not yet, but it is being worked on.  (Interested to take part?;-)
> 
> Agh, does that mean I have to pull my finger out?
> 
> I think I've got the compiler side working in an older beta, but the 
> rtl has to be modified to support it.

I think I can do the RTS part, if you send me a patch for your changes,
along with a short description about how you did it.

I'd imagine I'll do it as follows:

- Whenever an I/O function encounters an error condition, it sets InOutRes to
  the according error code (which will, of course, *not* be the same as in
  BP ;-), and return in a clean state. (The latter is the difficult bit; I've
  already done so for the Read/Write procedures, but I expect there will be
  more to do so that the program can continue safely.)

- At the start, each I/O function checks InOutRes, and if <>0, returns
  immediately, doing nothing. (Like BP does.)

- After calling an I/O function, if {$I+} is turned on, the calling program
  must check InOutRes. The code to be generated (perhaps you've already done
  so) would look like "if InOutRes<>0 then _p_ioerror;" where _p_ioerror will
  be a RTS function I can provide. (The check "if InOutRes<>0" could also be
  done in the function (like in BP!), but that's inefficient, because the
  function has to be called after each I/O operation then.)

Does this seem OK to you, or to anyone else? Any comments?

One question is what kind of errors is to be considered as I/O errors. E.g.,
overflowing the destination string length in WriteStr, if the automatic
truncating of strings (an option that will be introduced soon) is turned off,
is this an I/O error or rather a "generic" (string) error? Any opinions?
If there are more cases of doubt, I'll ask them here, too, when I find them.

-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
http://home.pages.de/~fjf/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)