Hi all
I have just uploaded BPCOMPAT v1.10 to agnes (in the contrib directory). You can download it as;
ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.zip and ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.txt
This version contains some bug fixes, and some stuff to improve portability (especially of the SYSTEM unit). Users of Linux and unix systems should find that the SYSTEM unit will now compile ("__UNIX__" is now predefined for Linux, Solaris, and FreeBSD - other unix users will need to define it manually).
There are probably still some remaining bugs, and the package is still not a complete replacement for the BP RTL. However, things are improving.
The ZIP file has been restructured (with a directory tree) so that the files are easier to locate and manage.
The package needs improvement, and all contributions are welcome!
BUGS ---- If you find bugs, please try to fix them - but please report them to me as well. If you fix them, please let me have a copy of the fix.
Happy coding!
Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12@keele.ac.uk Author of: Chief's Installer Pro 4.01 for Win16 and Win32: Winner of PC PLUS Magazine Gold Award (April 1995 U.K. edition) http://ourworld.compuserve.com/homepages/African_Chief/
ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief401.zip
BUGS
If you find bugs, please try to fix them - but please report them to me as well. If you fix them, please let me have a copy of the fix.
I haven't found any bugs, but I have a suggestion which -- IMHO -- would improve ValReal (the same applies to ValInteger, etc).
First, my modified ValReal; second, an explanation of the modification.
type str255 = string [255];
function sscanf (inputstr, format : pChar; ... ) : Integer; C;
Procedure ValReal ( S : str255; var Dest : Double; var ErrCode : Integer ); Var i, c : integer; Begin s[Length(s)+1] := chr ( 0 ); { s := s + chr(0) }
c := sscanf (pChar (@s[1]), "%lf", @dest); { Read double variable }
if (c = 1) then { sscanf returned one number = NO errors } begin ErrCode := 0; Exit; end;
{ There is an error in s; locate it for compatibility with BP Val proc }
{ check for non-numeric values} for i := 1 to length ( s ) do if s [i] in ['0' .. '9', '.', '-'] then {} else begin ErrCode := i; Break; end; end;{* ValReal *}
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.
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.
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. Of course, it cannot be range-checked ...
Best wishes,
Jesper Lund
Jesper Lund wrote:
BUGS
If you find bugs, please try to fix them - but please report them to me as well. If you fix them, please let me have a copy of the fix.
I haven't found any bugs, but I have a suggestion which -- IMHO -- would improve ValReal (the same applies to ValInteger, etc).
First, my modified ValReal; second, an explanation of the modification.
type str255 = string [255];
[...]
Ok - thanks. I note Frank's comments - and so I will leave "Val" alone. Frank - will your "Val" procedure deal with reals as well?
- 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]).
In GPCTYPES.PAS (soon to be merged with SYSTEM.PAS), "string" is redefined as "bpstring", if "_Borland_Pascal_" is defined.
- 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. Of course, it cannot be range-checked ...
Yes, it is. This is how it is implemented in "AddNull", which was in the strings unit before, but I have now moved it into the system unit, since the system unit also uses that functionality.
Any thoughts on whether the system unit should now export this AddNull function so that it can be available globally? This would introduce something which is not in the BP system unit.
Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12@keele.ac.uk Author of: Chief's Installer Pro 4.01 for Win16 and Win32: Winner of PC PLUS Magazine Gold Award (April 1995 U.K. edition) http://ourworld.compuserve.com/homepages/African_Chief/
ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief401.zip