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.