Get$ command behaviour...

[Coda]

BCX's GET$ command does not put a null character at the end of the data, in the string used to retrieve information from a random access file. I am not sure if this is an intentional 'feature' or if it is dictated in some way by C, however, it causes a problem if you ever use the same string variable to contain longer strings before using the GET$ command to retrieve shorter ones, for obvious reasons... a lot of garbage at the back end of the string and an incorrect string length.

Using X$ = "" before using GET$ doesn't help as that just seems to place a null character in the first byte of the string without similarly resetting the rest of the string's bytes, which, of course, doesn't help at all.

[airr]

Hi, Coda.

You'll need to null-terminate the string after the call to GET$. 

The example in the help file at https://bcxbasiccoders.com/webhelp/html/getstatement.htm shows what I mean.

AIR.

[Coda]

Hi Thankyou. What was going on was reasonably easy to work out for someone who has done very minimal C, such as myself... How to fix the problem was not so obvious to a non-C programmer. I wonder if BCX could be modified to null terminate unless there is some major advantage in not doing. Most BASIC-only programmers will be left scratching their heads at this behaviour, probably wondering what is going on, let alone how to fix it. I know it is alluded to in the help file but it just didn't jump out...

[Robert]

Hi Thankyou. What was going on was reasonably easy to work out for someone who has done very minimal C, such as myself... How to fix the problem was not so obvious to a non-C programmer. I wonder if BCX could be modified to null terminate unless there is some major advantage in not doing. Most BASIC-only programmers will be left scratching their heads at this behaviour, probably wondering what is going on, let alone how to fix it. I know it is alluded to in the help file but it just didn't jump out...

GET$ and PUT$ are for working with BINARY data which can include NULL as well as all other characters of the 255 char ANSI block. When working with BINARY data, the coder must keep track of size and location.

What are you trying to do ?  What's the problem ? Post your code.

[MrBcx]

BCX's GET$ command does not put a null character at the end of the data,

CORRECT.  That's absolutely the way GET$ is designed to work.

however, it causes a problem if you ever use the same string variable to contain longer strings before
using the GET$ command to retrieve shorter ones, for obvious reasons... a lot of garbage at the back end of
the string and an incorrect string length.

That is YOUR problem to solve, not BCX's problem.

As Robert already stated, GET$ and PUT$ are designed specifically for reading and writing binary data.
Everything from reading binary image data, video data, sound data, binary large objects (blobs),
business records, etc. often include multiple embedded nulls, so to expect GET$ to add a null doesn't
make sense, because in most cases, doing so would serve no useful purpose.

[MrBcx]

Using X$ = "" before using GET$ doesn't help as that just seems to place a null character in the first byte
of the string without similarly resetting the rest of the string's bytes, which, of course, doesn't help at all.

Coda,

There are several ways to clear a string variable's memory. 


If using a simple static string:

DIM MyString as STRING

CLEAR (MyString)  ' This BCX command will zero out the entire string.

CLEAR is simple wrapper macro for the CRT runtime function: memset

Clear(arg)memset(&arg,0,sizeof(arg))



If you are using a dynamic string:

DIM MyString * 5000



You cannot use the CLEAR command with dynamic strings but you can use memset directly:

memset (MyString,0, MEMSIZE(MyString))