71b creating strings with binary data

[dmh]

Hi, I'm trying to build binary data in a string for transmission via IL and the strings will contain unprintable characters including 0 (ie 0x00).

The problem I am having is that whenever I use CHR$() to place a value in a specific position in the string all preceding bytes with 0x00 in them are replaced with the space character.

Is there a way around this or a better way to do it? Resetting the spaces to 0x00 after CHR$() would be time consuming and error prone and I wanted the default to be 0x00 unless I assign a value.

I thought strings would be the best way to build such data and then output it all to IL using the string at once.

In the following example the string initially contains 0x00 but once CHR$() is used to place a value in character 5 the preceding characters are changed to space (even if I zero the preceding characters first after DIM).

Code:

DIM P1$[10]
NUM(P1$[1])
0
P1$[5,5]=CHR$(42)
NUM(P1$[1])
32

Any advise appreciated.

Edit: it doesn't matter if you use CHR$() or a character directly (eg "*") as the same issue occurs but as much of the data will be binary I will typically be using CHR$()

[J-F Garnier]

Using strings with binary data is usually no problem. I did it a lot of time.
However, the BASIC string type is not an array of bytes, but a string of characters associated with a length.

When you set the value of a character before setting the preceding bytes, these ones are not replaced by spaces, they are, by default, initialized as spaces.
Doing NUM beyond the current length of the string returns 0, not the (default) value of the character that is at this point outside the string.

If you don't set the value of each byte of the string, it means that they are don't care for you, so it shouldn't matter if there are spaces or nulls.
If it really matters for you, then you should initialize the string:
DIM P1$[10]
P1$=RPT$(CHR$(0),10)
or a loop if you don't have a LEX with the RPT$ keyword.

J-F

[dmh]

I actually did exactly that but didn't show it in the example above. I dimensioned the string, looped and set every character to 0x00 and then set a character in the middle of the string and all the preceding characters get set to space.

I tried it in emu71 and a physical 71b and got the same result.

Null / 0x00 is the problem, any other character (eg 0x01 etc) is fine but 0x00 gets changed to space.

I would have thought it had been done before. How did you do it? Do I need the length of the string set first so the 0x00's are not replaced?

I note that the 41C handles it by requiring a prefix character at the start of the ALPHA register to support null characters.

EDIT: Ok, I think it must be the length, I don't care about the length as I'm using DIM but I'm guessing inserting a character does so I will test again with the length set - thanks!

(12-20-2022 09:50 AM)J-F Garnier Wrote:  Using strings with binary data is usually no problem. I did it a lot of time.
However, the BASIC string type is not an array of bytes, but a string of characters associated with a length.

When you set the value of a character before setting the preceding bytes, these ones are not replaced by spaces, they are, by default, initialized as spaces.
Doing NUM beyond the current length of the string returns 0, not the (default) value of the character that is at this point outside the string.

If you don't set the value of each byte of the string, it means that they are don't care for you, so it shouldn't matter if there are spaces or nulls.
If it really matters for you, then you should initialize the string:
DIM P1$[10]
P1$=RPT$(CHR$(0),10)
or a loop if you don't have a LEX with the RPT$ keyword.

J-F

[J-F Garnier]

(12-20-2022 10:07 AM)dmh Wrote:  I actually did exactly that but didn't show it in the example above. I dimensioned the string, looped and set every character to 0x00 and then set a character in the middle of the string and all the preceding characters get set to space.

I can't reproduce it.
>DIM A$[10]
>FOR I=1 TO 10 @ A$[I,I]=CHR$(0) @ NEXT I
>LEN(A$)
10
>NUM(A$[2])
0
>A$[5,5]="A"
>NUM(A$[2])
0

(12-20-2022 10:07 AM)dmh Wrote:  How did you do it?
Do I need the length of the string set first so the 0x00's are not replaced?

I usually do it in this way:
I append all the bytes successively, in order, so the length is automatically managed.
DIM A$[N]
A$=""
FOR I=1 TO N
A$=A$&CHR$(x) ! append any byte including null
NEXT I

J-F

[Garth Wilson]

(12-20-2022 10:07 AM)dmh Wrote:  EDIT: Ok, I think it must be the length.  I don't care about the length as I'm using DIM

I don't think you can say that; because IIRC (although I haven't used my 71 in years), DIM only sets the maximum length; but if you're creating a new string variable with DIM (as opposed to re-dimensioning an already-existing one), the current length is initialized to 0. I think that after you do something that sets the current length as desired, you can change particular characters within that string to $00, without affecting others.

[dmh]

Thanks everyone for your replies.

My programming background is C which would work without issue doing something similar but I now understand the issue with 71b BASIC :-)

[KeithB]

Because C does *nothing* unless you tell it to do something. Sometimes it seems like malicious compliance. 8^)