WAD bpokestr issue

[TimButterfield]

In this example, I try to allocate a binary buffer of size 10 and write a repeated value into it. A smaller length value works, but not a value of length the same size as the binary buffer.

C:\tmp>ver

TCC  23.00.17 x64   Windows 10 [Version 10.0.17134.112]

C:\tmp>set b=%@balloc[10]

C:\tmp>echo %@bpokestr[%b,0,a,%@repeat[x,10]]
TCC: (Sys) The parameter is incorrect.
 "%@bpokestr[000001DCECC12080,0,a,xxxxxxxxxx]"

C:\tmp>set value=%@repeat[x,10]

C:\tmp>echo %@bpokestr[%b,0,a,%value]
TCC: (Sys) The parameter is incorrect.
 "%@bpokestr[000001DCECC12080,0,a,xxxxxxxxxx]"

C:\tmp>echo %@len[%value]
10

C:\tmp>echo %@bpokestr[%b,0,a,12345]
0

C:\tmp>echo %@bpokestr[%b,0,a,1234567890]
TCC: (Sys) The parameter is incorrect.
 "%@bpokestr[000001DCECC12080,0,a,1234567890]"

 

[vefatica]

10 characters is too many for a 10-byte (string) buffer. Internally the string will be terminated by a NUL character.

 

[TimButterfield]

I know about the need to allocate for the terminating NULL char in C/C++. Been handling that for decades. But, if that is a limit in the TCC language, it's not documented in an obvious way. The example for @bpokestr uses a buffer of 128, though writing a shorter string. Maybe I missed it, but I didn't see anything in the function docs about needing to allocate more or write the string to the buffer in blocks. If I allocate @balloc[%@inc[%size]], then the %size string will write fine. I cannot guess at intentions and can only go by the documentation.

 

[vefatica]

You're right. A note in @BPOKESTR's help is in order, perhaps something as simple as

Note that strings are automatically terminated by a NUL character. So an n-character string will require an n+1-character buffer. That's 1 extra byte for an ASCII string, 2 extra bytes for a Unicode string.

 

[TimButterfield]

Then, we get into the related issues of needing to NOT fill that position in a string, of writing the trailing NULL, possibly not when reading, or when using that binary buffer such as for unqlite. But, I'm not sure if these requirements are intended to force someone using TCC to think like a C/C++ developer.

 

[rconn]

WAD - as Vince suggested, when writing strings they are terminated by a null byte (or two for Unicode). Changing that now would break @BPEEKSTR.

If you want to write characters to a binary buffer that aren't strings, use @BPOKE.