For anyone following along that is not familiar with
C, a BYTE in C is called a Char in C. (Causes
some interesting conversations when UTF16 gets involved.)
On 2020-01-17 17:03, Paul Procacci wrote:
>> Take a peak at N1570, 5.2.1p2, 7.1.1 and 6.7.9,p14.
>> leaving off the nul is not a valid way of presenting a
>> string to a C function.
Here's the rub though Todd. Who is saying it's a string that is being
passed? (Hint: You are)
True. And one other place too:
https://docs.raku.org/language/nativecall#Passing_and_returning_values
The paragraph with the mistake in it is specifically
talking about strings.
For strings, there is an additional encoded trait
to give some extra hints on how to do the marshaling.
To specify how to marshal string return types, just
apply this trait to the routine itself.
Note that a NULL string pointer can be passed by
passing the Str type object; a NULL return will
also be represented by the type object.
At what point to you consider that they are actually speaking
about C Strings? Then they proceed to construct an
"undefined" array, not a C String.
If the intention is to pass 3 bytes "FOO" starting at a given memory
address, then it's exactly as it should be.
That is a string literal, not a string.
If the intention is to pass 4 bytes "FOO\0" then yes, it's a
documentation problem.
Now we are talking.
The reason for this ambiguity is because the prototype accepts either-or
of those interpretations.
The documentation should so state. It should make
the distinction between strings and arrays (string
literals). Instead it blabs on and on about strings
and the tells you how to convert an "undefined" array.
It is clearly a mistake.
You can't make any definitive declaration without looking at the
function body.
A 'char *' doesn't automatically mean a NULL terminated string. YOU are
making that assumption.
It could simply accept a 3 byte character array and we're done.
You missed my point. The structure required a
companion variable to give the array's length.
An actual C String stands on its own.
I'm familiar with C, in fact it's my bread and butter. Quite frankly, I
don't need the copy/pastes
from outside sources as I know for sure that everything I've stated here
is 100% accurate.
That would make you the PERFECT person to clean up the documentation and
make is usable to the rest of us!
If you are one of Raku's developers, would you please
consider taking over NativeCall's documentation page?
We need you!
I wasn't quoting N1570 to be annoying. I am quoting it
to make sure folks know I am not blowing smoke
out my ears (I make a lot of mistakes) and that
the information is trustworthy. It is not
my "opinion". It is fact.
>> C can not figure out where the end of the string
I don't see a string. I only see a Character Array.
EXACTLY! That was my point. The two are different.
How did you like the example program they guys on the
C group give me?
And as far as the careening going: MAKE IT STOP!!!!!
All it takes is three letters: ", 0".
-T
