The Sinclair QL Forum

Chain-Q wrote:There are some pre-made sysutils tests in directory tests/test/unit/sysutils. Not sure all can work as-is on a QL

Thanks. I had a look and there's quite a lot going on that the QL cannot (yet?) handle such as changing directories and so on. I've written a few minimalist test programs for the various routines mentioned above, and so far, some work! Those being:

• FileCreate()
• FileClose()
• DeleteFile() works fine, if run on a QDOS system where deleting a non-existing file returns ERR_NF (not found) but on SMSQ that errors is trapped and cleared, so DeleteFile() is not up to Free Pascal standards if executed against a missing file on SMSQ.

I've got a couple of failed tests with RenameFile() and OpenFile() to work through, later.


Cheers,
Norm.

More heads up: yesterday Frank Wille released vlink 0.16h which contains the QL target, Free Pascal will need at least this version real soon now, so please update your vlink builds. I have already updated the QL page on the Free Pascal wiki to signal this version or newer is now required. Probably Norman's doc need to be updated too. Edit: now made a PR against Norman's doc.

Chain-Q wrote:Probably Norman's doc need to be updated too. Edit: now made a PR against Norman's doc.

Thanks Chain-Q the document is now at release 1.2 with your change merged. The link is, as ever, https://github.com/NormanDunbar/FPC-Cro ... ses/latest.

I've downloaded the 16h source and built a new version, following the document instructions, and it still works! (As expected seeing as how it's just a cd and make!) In the process of rebuilding the cross compiler/rtl/ql units now.

Cheers,
Norm.

In the process of rebuilding the cross compiler/rtl/ql units now.

Sorry, that was a bit premature, I haven't changed anything in FPC yet, precisely to give people time to update their vlink. I will do it in the next few days. Just for clarification.

Chain-Q wrote:

In the process of rebuilding the cross compiler/rtl/ql units now.

Sorry, that was a bit premature, I haven't changed anything in FPC yet, precisely to give people time to update their vlink. I will do it in the next few days. Just for clarification.

No worries, at least the new version of the linker works! Everything built with only the usual warning messages.

Cheers,
Norm.

Everything built with only the usual warning messages.

So, I flipped the switch, and now, and after r49296, FPC now indeed needs vlink 0.16h. Additionally, I fixed the linker warning in r49295.

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.

NormanDunbar wrote:<>
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?

<>

I think the reason SMSQ/E doesnt return an error on delete file not found is that it doesnt matter: Whether the file to be deleted is found or not, the result is the same; the file is gone, just as the customer ordered.
What would be the point of getting an error? To give one the chance to create the file so it could be "legally" deleted? No, it would just be an unnecessary annoyance.

Hi Per,

yes, understood. It would be a problem, but in order to match up with the Free Pascal specs/docs (pick one!) it should return an error if a file to be deleted doesn't exist.

Somewhere back in this thread/topic, Marcel posted a bit of code from SMSQ which checks the return from IO_DELET/IOA_DELF and zeros out D0 if the error code is ERR_NF, so it's a deliberate change in SMSQ. QDOS, of old, on the other hand, does return an error for attempting to delete a non-existent file.

Anyhow, I'm not worrying about it, only documenting the fact that in testing, it doesn't match the requirements.


Cheers,
Norm.

NormanDunbar wrote:<>Somewhere back in this thread/topic, Marcel posted a bit of code from SMSQ which checks the return from IO_DELET/IOA_DELF and zeros out D0 if the error code is ERR_NF, so it's a deliberate change in SMSQ. QDOS, of old, on the other hand, does return an error for attempting to delete a non-existent file.<>

I know. I was there! And, having pondered the matter, what Im trying to say is: My theory for why TT did it is: 'Cause its the smart thing to do! (And to hell with everyone's OCDs!)