PTR# and !ABC

It looks like the PTR# command in BASIC doesn’t compile well in !ABC.
We can read a disc file byte by byte, using BGET#, or string by string, using GET$#. In my program I prefer the latter, since it’s faster and much easier to check for patterns. However, sometimes the routine encounters strings that exceed the 256 bytes limit. I intercept that by checking the length of each string. If it is 255, I redirect it to a routine that reads the line byte by byte, after having set the file pointer back: PTR#f% = PTR#f% - 255.
This goes well as long as I stay in BASIC, but it produces a mess after compilation. Is this a known issue, or have I found a new bug?

(The solution, of course, is reading the entire file with BGET#, but I thought it’s worth mentioning here.)

Have you tried rewriting it as

PTR#f% = FNread_file_ptr(f%) - 255

DEF FNread_file_ptr(f%): =PTR#f%

[See below] Surely this approach fails if a line that’s read is exactly 255 bytes followed by a terminator: the file pointer will have advanced past the terminator, but you only retract 255 bytes. Or is it the case that BASIC doesn’t look for the terminator if 255 bytes have been read? The documentation isn’t 100% clear to me on that point.

Perhaps a different approach would be to take a note of PTR# before calling GET$#

Or is it the case that BASIC doesn’t look for the terminator if 255 bytes have been read?

It seems so, but actually I’ve no idea. Perhaps none of the files that I’ve read contain strings of exactly 255 bytes. My point however was that it works in BASIC, but fails after compilation.

PTR#f% = FNread_file_ptr(f%) - 255
DEF FNread_file_ptr(f%): =PTR#f%

Although I fail to see how this differs from PTR#f% = PTR#f% - 255, it might bypass the bug in !ABC, for one of those mysterious reasons. I will give it a try, although I’ve already removed the PTR# command completely from my program.

Or is it the case that BASIC doesn’t look for the terminator if 255 bytes have been read?

BASIC does indeed give up once 255 bytes have been read, without looking for a terminator after the last byte. The BASIC Reference Manual could be clearer on this point.

BASIC does indeed give up once 255 bytes have been read

BASIC’s string handling when it comes to over-long strings is bordering on the dangerous. Here’s an artificial example of something that caught me out:

>DIM x% 4095
>FOR l% = 0 TO 4095 : x%?l% = RND(26)+65 : NEXT
>x%?4095 = 0
>SYS "XOS_GenerateError", x% TO x$
>P. x$, LEN(x$)
         0
>

It would have been better to either return the first 255 characters, or better yet, to return a “Too long” error.
To silently return an empty string is just bad.

The actual program handled lines read in from a socket connection, and some of the fancier cookies can be kind of lengthy. Of course, I could break it all down and read the data in itty bitty chunks to appease BASIC (the payload is GBPB’ed out of a buffer, it was just header processing)…
…or do what I did and just switch to C where it doesn’t sulk over a 300 byte string.

The BASIC manual doesn’t mention this behaviour either. ;-)

BASIC does indeed give up once 255 bytes have been read

That is true, because it cannot put any more data into the string it is assigning to as 255 is the max length. At that point, if the LEN of the string is 255, you can issue another GET$# to get the next part of the string. I have used that technique occasionally.

However, these days with less memory constraints, unless the file is very large I tend to load the whole file into memory using just a OS_File to read the length, DIM a block (LOCAL if possible), the OS_File to read the whole file and process it in memory. Generally much faster. If very large I have done similarly for a reasonaly big buffer-full at a time.

you can issue another GET$# to get the next part of the string.

Strike me, I would never have thought that. And it would have helped me indeed. On the other hand, reading the entire file with BGET# isn’t exactly troublesome either and it always works, no matter how large the strings involved are.

But the point was that PTR# gets mangled when compiling.