libzigc for freestanding targets

[alexrp]

Originally posted by @andrewrk in #24558

But one of the main use cases for zig libc is freestanding. So these functions should be exported when the target is freestanding or other

I agree that this is a good use case for libzigc. From the PR description of #23529:

I repurposed the existing "universal libc" code to do this. That code hadn't seen development beyond basic string functions in years, and was only usable-ish on freestanding. I think that if we want to seriously pursue the idea of Zig providing a freestanding libc, we should do so only after defining clear goals (and non-goals) for it. See also #22240 for a similar case.

What I meant by this is that we should define a clear subset of the C standard library that we are interested in providing in freestanding libzigc. This will also mean answering various ABI questions; for example, it's easy to say that we want to have all the string and math functions, but is our char unsigned or signed? What's our wchar_t defined as? What about double on platforms like AVR (where it's sometimes, but not always, equal to float)? So on and so forth. We also need to figure out if we want to provide more complex functions that might require memory allocation or system interaction, and if so, how we want to allow users to fill in the missing bits (e.g. malloc), which will mean defining a stable "system <-> libc ABI" of sorts.

Implementing a universal libc, especially one that works on freestanding, is not as straightforward as it sounds due to issues like this, and I think we'd be doing a disservice to potential contributors if we don't have answers to at least some of these questions before we open this task up for contributions, since they might write code that we decide we're actually not satisfied with.

[andrewrk]

What I meant by this is that we should define a clear subset of the C standard library that we are interested in providing in freestanding libzigc

Noting that with the upcoming Io interface, this subset can include the vast majority of functions, relying on the user to export only a single *Io pointer for freestanding zig libc to depend on.

Likely, users would want to take advantage of including zig libc into their application so that it shares the compilation unit with their Zig code, and then Io functionality can get inlined into the exported libc functions.

[alexrp]

I definitely don't know enough of the nuances of libc's system-dependent APIs to say whether that's doable, but assuming it is, that sounds reasonable to me.

That said, wouldn't it put some annoying extern constraints on Io?

[haydenridd]

Tagging @ikskuh as he created Foundation Libc which is in the same vein as some of things being discussed here! I would definitely be interested in helping implement what this looks like for freestanding once the desired subset is clearly defined like alex mentioned above.

[andrewrk]

That said, wouldn't it put some annoying extern constraints on Io?

not if sharing compilation unit with the zig application

[mlugg]

So, being pedantic for clarity:

relying on the user to export only a single *Io pointer

The word "export" here isn't correct. You'll just need to provide it, within the ZCU, somehow. For instance, perhaps libzigc would use @import("root").libzigc_io.

Of course, we can do the same for malloc and friends, e.g. by libzigc using @import("root").libzigc_allocator. (We'd need to track metadata on the allocations though, since the C allocation API doesn't provide allocation lengths when freeing.)

[KilianHanich]

While it's likely that ziglibc will provide more, it should at the very least provide every header which freestanding libcs are supposed to provide, even if it isn't a lot (as a source this: https://wiki.osdev.org/Implications_of_writing_a_freestanding_C_project).

It's probably also good if some form of properties get defined to make the decision of which things gets included and which not more clear. For example Unicode will not get supported (the next C standard will get a full blown Unicode conversion functions to a point where it makes a lot of existing libraries look bad). This would obviously not be supported but ziglibc. On the other hand maths functions could likely be supported quite well.

[KilianHanich]

As far as the signedness of char is concerned, here a link to compiler explorer: https://godbolt.org/z/bhjjMMzfr

The signedness of char is kind of a mess.

On x86_64 it seems like things settled on char being signed, and I kinda would be in favour to extend this to ziglibc in general (if ziglibc decides to have the same on all platforms) since a lot of C code is these days written with only x86/x86_64 in mind (which is also a problem for a lot of companies when porting their software to ARM, especially Windows on ARM).

On ARM it is a mess. The instruction set does apparently not include a signed byte load which caused GCC and clang to define char as unsigned on these platforms. On the other hand macOS and Windows defined char to be signed on their ARM platform (see above on x86_64 why I think that's a good idea).

RISC-V decided to write the decision if char in C is signed or unsigned by default into its ISA specification and decided on unsigned: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf

[haydenridd]

Without getting too hung up on one thing, could signed vs. unsigned char be determined based on target like it is currently (see here) but with an added configuration option (exe.char_signedness = .signed or something) in build.zig? This option would end up reducing to the -fsigned/unsigned-char flag for LLVM. Presumably then the Zig implemented C std. lib would just follow the build settings for signed vs. unsigned char (since presumably it would use the c_char type in its exported function signatures) unless I'm grossly misunderstanding something!