>> 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) If the intention is to pass 3 bytes "FOO" starting at a given memory address, then it's exactly as it should be. If the intention is to pass 4 bytes "FOO\0" then yes, it's a documentation problem. The reason for this ambiguity is because the prototype accepts either-or of those interpretations. 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. 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. >> C can not figure out where the end of the string I don't see a string. I only see a Character Array. On Fri, Jan 17, 2020 at 7:06 PM ToddAndMargo via perl6-users < perl6-us...@perl.org> wrote: > On 2020-01-17 15:34, Paul Procacci wrote: > > Todd (and others), > > > > So a few things. > > > > 1) > > JJ's example worked by chance. (sorry JJ). > > It worked because it just so happens that either his OS zero filled the > > block he was allocated by the allocator > > or because he didn't reuse the block that was given to him initially by > > the allocator. > > > > 2) > > If you assume that the function set_foo($array) expects a NULL > > terminated string, only then is the documentation a problem. > > However, there's not enough information in the C prototype to make this > > assumption. There's also no set_foo($array) function body to explore. > > > > # C prototype is void set_foo(const char *) > > > > > > All this says is that the subroutine is receiving a pointer to memory > > containing bytes and nothing more. > > The body of the function _may_ simply check the first 3 bytes. This is > > up to the reader to ascertain. > > > > 3) As for a documentation update, I'm unsure if it's required. The > > example is not only perfectly valid raku, it's also perfectly valid C. > > Actually, it is not perfectly okay with C. Let me state > my case: > > 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. > > C can not figure out where the end of the string is > on its own without the nul. It will careen until it > find a nul. Even further if the string is UTF16 and > is looking for a double nul (0x0000); > > Now if you want to do a "String Literal", you can > leave the nul off. But it required that you inform > to other end as to the String Literal's length. And > a "String Literal" IS NOT a C string. > > "String Literal's" are covered by N1570 6.7.9,p14 > > An example of a string literal can be found at: > > > https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw > > "const BYTE *lpData" points to the String Leteral, and > > "DWORD cbData" contains the length of the string literal > > C Strings and String Literals are two vastly different things. > > In that same example: > > "LPCWSTR lpValueName" points to a C String that must > be nul terminated. Note that there is no companion > variable stating its length > > > > Perhaps something could be added to remove whatever ambiguity you > > perceive, but you argument stems from something that isn't necessarily > > true in this example > > and that's the function set_foo($array) expects a NULL terminated string. > > > > ~Paul > > Hi Paul, > > This is the example I previously posted of careening > that drove me crazy trying to troubleshoot. The C guys > told me it was not a convincing example. > > https://ibb.co/tHy7ZQM > > The C Spec N1570, 5.2.1, p2 is very clear: > > A byte with > all bits set to 0, called the > null character, shall exist in the basic > execution character set; it > is used to > terminate a character string. > > > And not including it causes all kinds of consternation, > as I found out the hard way. > > -T > -- __________________ :(){ :|:& };:
