This commit adds strdup and strndup based on musl.
Contributes to: #30978
chrboesch/zig:libzigc_string into master This commit adds strdup and strndup based on musl.
Contributes to: #30978
lmk if you want help understanding those failures. By the way, thanks a ton for your work maintaining ziglings!
Thank you very much, I gladly accept your help. After reading the error message, I think I've identified my mistake. I followed the Zig convention and expected an external allocator, which isn't the case with a C function (apart from the function signatures, which are also incorrect). Since nobody has yet implemented a function that requires malloc (at least I haven't found one), I lack the blueprint. However, I see that malloc has already been implemented and I am wondering how this is supposed to work: should I import malloc from malloc.zig, or what is the idea behind it, and is my analysis generally correct?
Rather than additionally reviewing an old, abandoned PR, I'll just review yours, hopefully that helps :-)
@ -164,6 +166,18 @@ fn strtok(noalias maybe_str: ?[*:0]c_char, noalias values: [*:0]const c_char) ca
returnstrtok_r(maybe_str,values,&state.str);
}
fnstrdup(allocator:std.mem.Allocator,s:[]constu8)error{OutOfMemory}![]u8{
Consider carefully what the function signature should be:
@ -165,2 +167,4 @@
}
fnstrdup(allocator:std.mem.Allocator,s:[]constu8)error{OutOfMemory}![]u8{
returnallocator.dupe(u8,s);
I recommend to port the musl logic directly rather than doing this.
Thanks. Now I have ported the musl logic directly, but I need malloc in string.zig. Should I make malloc in malloc.zig public and @import it, or declare it as extern fn in string.zig: extern fn malloc(size: usize) ?*anyopaque;?
But I could also extract a malloc_inner as you described in #31144
Any C functions you need you should get from std.c. In this case it looks like malloc is already there, so you should be good.
Now that I see it works, I will also take over the wasm function.
@ -165,2 +168,4 @@
}
fnstrdup(str:[*:0]constc_char)callconv(.c)?[*:0]c_char{
conststr_u8:[*:0]constu8=@ptrCast(str);
I think you should be able to implement these functions without this @ptrCast - please do that whenever possible, because it makes the code simpler and easier to verify. You'll still need one from malloc's return value, which is OK.
done
The code in lib/std/c/test.zig goes in test/c/ somewhere.
wcsdup.c file should be deleted
I've moved all the tests to /test/c/string.zig, including wscdup. Is that okay, or should I create a separate test file for them?
@ -192,0 +197,4 @@
constsize=(len+1)*@sizeOf(wchar_t);
constd_opaque=c.malloc(size)orelsereturnnull;
constd:[*]wchar_t=@ptrCast(@alignCast(d_opaque));
_=wmemcpy(d,str,len+1);
should be return wmemcpy(... like the musl source
@ -13,0 +52,4 @@
trytesting.expectEqualStrings("Hello",std.mem.span(@as([*:0]constu8,copy3_u8)));
}
test"wcsdup"{
Please move to a new test/c/wchar.zig file to maintain symmetry with the implementation code.
done
@ -12,1 +12,4 @@
}
test"strdup"{
if(builtin.target.os.tag==.windows)return;// no strdup
why do you think this?
UCRT on Windows does have _strdup, but as I understand it, that would only forward the test to their library and not test our Zig function.
I don't really know much about Windows; I was just trying to understand how library calls work under Windows and where the error messages came from. If it turns out that's not the case and the tests do have the desired effect, I'll remove this skip again.
As of #31923 being merged, we do want the libc API tests to run against all libc code, even if it's not ours.
According to https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strdup-wcsdup, the strdup and wcsdup symbols in std.c should link to _strdup and _wcsdup on Windows (see the private namespace there for examples of how you can accomplish this without exposing both names).
It does appear that strndup doesn't exist on Windows, however, so the Windows check in that particular test is appropriate.
It does appear that strndup doesn't exist on Windows, however, so the Windows check in that particular test is appropriate.
Why don't we simply provide all the functions on all the targets?
Because we're matching existing libc ABIs. If we provide a symbol that the 'real' libc doesn't provide, it means that link tests in build systems will succeed where they shouldn't, and/or people will write code assuming the presence of a symbol only to discover that it's not there when using a compiler that isn't zig cc but which ostensibly targets the same ABI.
I'm not opposed to providing a better libc that doesn't have seemingly arbitrary gaps like this, but as with other questions that have to do with differences in the libc ABI surface or observable behavior, my opinion is that this should be done under a different std.Target.Abi tag.
but strndup has been part of posix since 2008
Now you're entering the world of standardization, and the question of why Microsoft doesn't adhere to standards fills thick files here. They prefer to define their own (mostly proprietary) things so that their competitors (if you can call them that) have a harder time.
Fortunately for everyone, things are changing a little (especially in the EU), but whether they will include strndup in their library is another matter. But how to deal with this now, I (unfortunately) cannot answer that question.
strndup seems to also be C23 and added to mingw a few days ago.
I've removed the skips except for strndup. If the feature is actually implemented, I can remove that skip later as well.
OK, nice, it looks like this made it across the finish line.
3 down, 1855 to go!
that's my blueprint now!
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?