Yippee! progress on SysUtils unit.
The attached patch file (FPS.patch.7.zip) is all the changes to bring the sysutils.pp file up to date with my work. You can apply it as per the instructions in my document which is found at
https://github.com/NormanDunbar/FPC-Cro ... ses/latest as usual. A number of the FileXxxxx functions and procedures have been created and tested to desctruction. Almost all work as per the Free Pascal Wiki on SysUtils, but one doesn't. FileDelete() on SMSQ doesn't report an error if the file doesn't exists whereas QDOS does. This makes the SMSQ version of Free Pascal slightly inconsistent with the docs. However, once I get FileExists written and tested, I can add a check before trying the delete.
EDIT:
The afore mentioned document is now at release 1.3 as of April 30 2021. I've corrected some spelling and grammar errors, added links to Marcel's Web Site and removed an "interesting" code example that nobody seems to have noticed was in completely the wrong place!
RenameFile() isn't yet working. But I'll figure out why, eventually.
Here's the patch file:
and what follows is a test log for each of the new/amended functions in the SysUtils unit.
Sysutils Unit - Testing.
FileCreate:
Appears to be fully working:
- Creates a new file provided name is correct.
- File remains open until closed or job exits.
- Overwrites existing file with same name.
- Fails (-1) if invalid filename supplied - no device part.
- Fails (-1) if device name '0' supplied.
- Fails (-1) if device name '9' supplied.
- Fails (-1) if 37 character filename is supplied after device name.
FileClose:
Appears to be fully working:
- Closes a valid file handle returned from FileCreate().
- Does not cause runtime errors if passed an invalid handle.
DeleteFile:
Appears to be fully working but only as per SMSQ. If a file is not found, no errors are returned. Basically, always returns true on SMSQ. On QDOS, it
should return an error.
- Deletes an existing file, returns true.
- Doesn't delete a missing file, but still returns true -- as per the SMSQ though. Problem?
FileOpen:
Appears to be fully working:
- Does not create a missing file as expected.
- Opens files happily in fmOpenRead mode.
- Opens files happily in fmOpenWrite mode.
- Opens files happily in fmOpenReadWrite mode.
- Fails when passed invalid file/device names.
FileWrite:
Appears to be fully working:
- Correctly casts Buffer to an address to write from.
- Correctly writes requested data.
- Returns -1 on errors.
FileRead:
Appears to be fully working:
- Correctly casts Buffer to an address to read into.
- Correctly returns data read.
- Returns -1 on errors.
FileSeek:
Appears to be fully working:
- fsFromBeginning maps to FS_POSAB. Positions to, and returns, correct offset.
- fsFromCurrent maps to FS_POSRE. Positions to, and returns, correct offset.
- fsFromEnd maps to FS_POSAB at EOF, then FS_POSRE with -(Offset). Positions to, and returns, correct offset.
- Does not return error if new pos > EOF? So correctly traps ERR_EF and clears it.
Not sure if the fsFromEnd action is efficient for multiple seeks from end. Setting to the EOF of a large file could take a while? Always setting to EOF then backing up by the required offset might not be wise? Efficient? A good idea? Anyway, it works.
FileTruncate:
Appears to be fully working:
- Returns true on success.
- Returns false on error.
- Correctly truncates the file at the correct offset. (File must be open in writ mode, fmOpenWrite or fmOpenReadWrite.)
Cheers,
Norm.