Trapping I/O runtime errors in GPC_(re)

Thu, 23 Oct 1997 02:42:26 +0200

Jesper Lund wrote:

> Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-}
> compiler directive in Borland Pascal?  Right now, the program
> 
> var
>   x : real;
> 
> begin
>   Readln (x);
> end.
> 
> abort with a run-time error if the user enters something that is not a
> number.  The same applies to ReadStr, BTW, so unless there is such a switch
> (hidden) in GPC, we have to call C functions like 'sscanf' or 'atof' to
> emulate the Borland 'Val' procedure.

There will be a built-in Val procedure in the next beta! :-)

> However, ReadStr + trapping runtime I/O
> errors would be simpler, IMHO.

AFAIK, Bill is working on the {$I+-} switch. (Bill, if you're reading this:
The places to trap this particular error are the calls to _p_generic() in
rts/rts-rdinc.c -- if you haven't done so already.)

>From another mail:

> I haven't found any bugs, but I have a suggestion which -- IMHO -- would
> improve ValReal (the same applies to ValInteger, etc).  

Not necessary any more. I just completed the RTS part of the Val procedure,
and Peter will build it into GPC.

> [code snipped]
>
> COMMENTS:
> 
> 1) The C library function converting the null-terminated string into a double
> checks for errors itself (sscanf returns 0 if the string cannot be converted
> to a double; meaning 0 values read from the string), so there is no need to
> parse the string (to find the position where the error occurs), unless there
> is an error in the string.  BTW, this speedup is not possible with atof
> because atof returns 0.0 if the string cannot be converted to a double. 
> That's why I use sscanf instead (sscanf is ANSI C, and must be in any C
> library, so no concerns about portability between Linux, DJGPP, etc).
> 
> As an aside, the string '1.1e3', is now converted to 1100.0, which is the
> correct behavior.  The code checking for errors should really be rewritten to
> handle this.  For example, the error position for '1.0ef3' is not at position
> 4, but the 'f' at position 5.  Adding 'e' to the list of admissible chars
> would improve things a bit, but still not totally correct.

In the built-in version (to come), I hope I've made all the checks at the
right places. When it's released, please do as extensive tests as you can,
and report any bugs you might find.

> 2) The formal parameter S is declared as a string[255], instead of the schema
> type 'string' (which has a different meaning than in Borland Pascal, where it
> means string[255]).  As you add a #0 to the string variable 's', it should be
> large enough not to overflow (length gets out of range).
> 
> I don't think the original version would work if called with a string
> constant, because S would be a string with the same length as the string
> constant, and adding #0 would (should) cause an exception.

Yes, we discussed this topic recently. We plan to build in some functions
for converting Pascal strings into CStrings easily.

> 3) Unless GPC is really good at optimizing string expressions, the "hack"
> 
>   s[Length(s)+1] := chr ( 0 )
> 
> is faster than adding chr(0) to the string variable.

Yes, it's faster. GPC is not that good yet, but I hope we'll make it that
good (but not until version 2.1)...

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

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