Just checking in Byte I/O about de-re-basic

[jMarcS]

Instead of "length string" it should be "string length", or "length of the string in the buffer variable".

Except for that, I'm not offering suggestions, only explanations. The original wording may not be precise, but it is certainly concise. There's a lot of information in there, and there's a lot of latitude in deciding how much to write.

There's a logical leap from the abstract "<buffer_svar>" to the concrete example "buf$". You're resolved it by referring to the string length function len() by name without an argument, which is a common practice but still requires the reader to make a logical connection, and without benefit of the telltale '$'.

There's another leap that takes longer to explain, but it's still logical. If you're reading data and you reach the end of the file, the buffer contains the data you read, so its length is not zero. If after reaching the end of the file you read it again, you don't get an error, and you don't get a special EOF indicator. You get an empty (zero-length) buffer. The only way to know you've read the entire file is to read it again until you get a zero-length string -- that is, until len(<buffer_svar>) returns 0. This may be counter-intuitive to a C programmer, or somebody who uses sockets a lot instead of files.

Finally, there is no mention of what happens if <count_nexp> is bigger than the file. Is that a sin of omission, or does leaving it out imply that BASIC! does the intuitively obvious "right thing"? Okay, that's reaching a little!

[mrleavitt]

Good points. Changed "length string" to "string length" (how'd I miss that?). Put in the parameter arguments explicitly instead of buf$. I'm passing on the fourth and fifth paragraphs as they move the text too far (IMHO) in the direction of a "how to" manual, as opposed to a reference manual. I'm certainly open to revisit this if anyone thinks I should.

[jMarcS]

I think you got it right.