>> 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.)
I don't want to make this about C, but to clarify there's no type called "BYTE" in the C language. If BYTE is defined it's system dependent and usually points to an unsigned char. >> The paragraph with the mistake in it is specifically talking about strings. That paragraph you quoted shows a message_box(Str) as the example. It's argument is undoubtedly expecting a NULL terminated string. However, your contention is about a set_foo(CArray[uint8]).. These aren't the same thing as I've already explained to you twice now. +--------+ With the above said, I personally _agree_ the documentation should be altered. This text preceding the example is what leads me to believe it should be: " If the C function requires the lifetime of a string to exceed the function call" This hints to me that the function call is in fact supposed to take a string. $array.elems currently shows 3 items w/ the following values: 0x46 0x4F 0x4F when I would expect, the CArray[uint8] to contain the following instead: 0x46 0x4F 0x4F 0x00 +--------+ In closing. if you have an example where you can get a garbage characters because of a bad example, then the example _should_ be updated. Without knowing Raku internals it's hard for me to say (I'm not a Raku dev) but I feel I'm on the right track. I've tried causing a segfault myself, but a trace of the small app always made new allocations (mmap - which zero's pages), so it's hard for me to duplicate such an error. On Fri, Jan 17, 2020 at 9:16 PM ToddAndMargo via perl6-users < perl6-us...@perl.org> wrote: > 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 > -- __________________ :(){ :|:& };:
