#578 OPENREAD cannot open a vbar'd filename with spaces in it

[David Costanzo]

OPENREAD throws an error if you give it a filename with spaces in it that was constructed using vertical bars. It does not throw an error if you give the same filename constructed with backslashes.

I have reproduced this on FMSLogo 8.2.0. I have also reproduced this on MSWLogo 6.5b, so this is not a regression. This is not reproducible on UCBLogo 6.2, so it should be straight-forward to port the fix to FMSLogo.

How Reproducible:
Every Time

Steps to Reproduce:

:::text
; Create a file with a space in its name
OPENWRITE "one\ space.txt
CLOSE "one\ space.txt

; Read the file using backslashes to quote the space
OPENREAD "one\ space.txt
CLOSE "one\ space.txt

; Read the file using vertical bars to quote the space
OPENREAD "|one space.txt|
CLOSE "|one space.txt|

What Happens:
The second OPENREAD throws an error:

:::text
File system error: Could not open file

Expected Result
The second OPENREAD does not throw an error. Neither does the final CLOSE.

[David Costanzo]

I have fixed this with [r5808]. The fix will be available in FMSLogo 8.3.0.

Vbar quoting is implemented by replacing the code point of a special character with a different code point of some unlikely-to-be-used character. In order to get back to the original character, the code point must be unmapped. This was not being done for OPENREAD, OPENWRITE, OPENAPPEND, or OPENUPDATE. As a result "|one space.txt| was being treated as if the space were some strange other character. So in the example given in the original bug description, OPENWRITE created a file with a space, but OPENREAD tried to read it with some other non-space character and that file didn't exist.

This is a bug is difficult-to-see. I must have looked at this code hundreds of times and never noticed it. I wonder how many other bugs like this exist in the code base. Now that I know what to look for, it may be easier to notice them.