On 1/2/21 8:13 PM, Paul Procacci wrote:
What I'm trying to attempt to do now is display the contents of that
CArray (raku member a). In my mind, this is an "array of utf16LE byte
sequences terminated by 0".
Hi Paul,
If I understand your problem, you are having trouble
extracting something usable from Windows return UTF16
string.
I have a series of modules I wrote to read and write
to the Windows registry. The strings I got back were
all "UTF16 little ending C Strings".
This means that every character is a TWO byte word
(16 bits) with the first byte containing the low
value byte. And they terminate with both bytes
being a numerical zero. It is a little weird to get
use to.
There was some interesting conversation in these
parts a bit ago as to if a C string could ever
not be terminated with a nul. They are always
terminated with a nul.
The following is from one of the modules I wrote to
support this. I used brute force, rather than
rely on UTF conversion utilities as I found them
unreliable.
If you un-comment
# print $CStr[ $i ] ~ "," ~ $CStr[ $i + 1 ] ~ ", ";
you can watch the sub do its thing.
I have a sub to go the other way too, if you want it.
HTH,
-T
use NativeCall;
sub c-to-raku-str( BYTES $CStr ) returns Str is export( :c-to-raku-str ) {
# Note: C Strings are always terminated with a nul. This sub will
malfunction without it.
# Note: presumes a UTF16 little endian C String and converts to UTF8
my Str $SubName = &?ROUTINE.name;
my Str $RakuStr = "";
my Str $Msg = "";
my uint32 $CStrElems = $CStr.elems;
# say $CStrElems;
loop (my $i = 0; $i < $CStrElems - 2 ; $i += 2) {
if $CStr[ $i ] == 0 && $CStr[ $i + 1 ] == 0 { last; }
if $i == $CStrElems - 4 {
$Msg = "$SubName ERROR:" ~ " C Strings are required to be
terminated with a nul\n\n" ~
" Returning an empty string\n" ~
" Cowardly existing\n";
exit;
}
# print $CStr[ $i ] ~ "," ~ $CStr[ $i + 1 ] ~ ", ";
$RakuStr ~= chr( $CStr[ $i ] );
}
# say "";
# say "$RakuStr";
return $RakuStr;
}
