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.
On 27 Oct 97 at 8:50, Frank Heckenbach wrote:
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'll have to sort though my mods to bring them up to date with the latest beta.
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.)
That's what I was hoping for.
- At the start, each I/O function checks InOutRes, and if <>0,
returns immediately, doing nothing. (Like BP does.)
I hadn't thought of that, but it's an excelent idea.
- 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.)
Actually, that's almost exactly what my mods do. If IO checking is enabled ( {$I+} ), a proceedure taking no parameters is called that would check the InOutRes state (though I used a different name) and if it's set dumps a dirty message and aborts the program. Bill -- Leave others their otherness.
-
Bill Currie -
Frank Heckenbach