> On 9 Jun 2021, at 06:34, Paul Procacci <pproca...@gmail.com> 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
>
> The decode documentation for Buf only states that 'Applies an encoding to
> turn the blob into a 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.
That is an incorrect assumption carried over from C. In the Raku Programming
Language, a null byte is a valid grapheme, as it is in unicode. A small change
to your program:
my Buf $b .= new(72, 105, 0, 32, 97, 103, 97, 105, 110, 0);
.say for $b.decode.uninames;
#####
LATIN CAPITAL LETTER H
LATIN SMALL LETTER I
<control-0000>
SPACE
LATIN SMALL LETTER A
LATIN SMALL LETTER G
LATIN SMALL LETTER A
LATIN SMALL LETTER I
LATIN SMALL LETTER N
<control-0000>
> 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.
I don't see an initial null in your example.
But yeah, the Str class in Raku is much more than a C-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.
If you want to include the null byte in your final strings:
my @strings = $b.decode.comb(/ .*? "\0" /)
would be a way.
> Another question might be, should decode() follow null terminating semantics
> instead of number of elements in a given Buf.
No. The C-string semantics are what they are. They are not the semantics used
in the Raku Programming Language.
Liz
