On 6/8/21 9:34 PM, Paul Procacci wrote:
Hopefully a pretty quick question....
GIven the following:
my Buf $b .= new([72, 105, 0, 32, 97, 103, 97, 105, 110, 0]);
say $b.decode;
I would expect this to print 'Hi'.
Instead it prints 'Hi again'.
https://docs.raku.org/type/Buf#(Blob)_method_decode
<https://docs.raku.org/type/Buf#(Blob)_method_decode>
The decode documentation for Buf only states that 'Applies an encoding
to turn the blob into a Str <https://docs.raku.org/type/Str>; the
encoding will be UTF-8 by default.'
The zero (0) in that Buf should imply an end of string yet decode seems
to want to decode the number of elements instead.
Furthermore, If I 'say $b.decode.chars;' it counts the initial null as
part of Str.
In my mind, that means Str doesn't really mean string.
So the question, how does one ACTUALLY decode what's in a buffer to a
string where it adheres to the semantics of NULL termination for strings
cleanly.
Another question might be, should decode() follow null terminating
semantics instead of number of elements in a given Buf.
Thanks,
Paul
Hi Paul,
In "C", a chr(0), also called a "null" is a string
terminator. In Raku, the terminator is in the
accompanying structure (hidden from you), when
says long the string is.
My guess as to what is happening is that the decode
function is simply giving you the ASCII (UTF-8)
value of chr(0). And that decode thinks the length of
the resulting string is the length of the buffer,
also in a hidden structure.
I would use a loop and the chr function to
make my own decode and terminate early is it find
a chr(0).
HTH,
-T
