zlacker

>>ingve+(OP)
Does this mean long term Zig won’t run on OpenBSD?

Because doesn’t OpenBSD block direct syscalls & force everything to go through libc.

>>38039689

>>tiffan+8M1
This affects static libc only. If you pass -dynamic -lc then the libc functions are provided by the target system. Some systems only support dynamic libc, such as macOS. I think OpenBSD actually does support static libc though.

>>AndyKe+9O1
> I think OpenBSD actually does support static libc though.

How does that work, with syscalls being unable to be called except from the system’s libc? I’d be a bit surprised if any binary’s embedded libc would support this model.

>>winter+XV1
Not all of libc is syscalls. E.g. strlen() is zib libc but open() goes to system libc.

>>preten+vY1
Good point. C's "freestanding" mode, analogous to Rust's nostd, does not provide any functions at all, just some type definitions and constants which obviously evaporate when compiled. Rust's nostd not only can compute how long a string is, it can unstably sort a slice, do atomic operations if they exist on your hardware, lots of fancy stuff but as a consequence even nostd has an actual library of code, a similar but maybe less organized situation occurs in C++. Most of the time this is simply better, why hand write your own crap sort when your compiler vendor can just provide an optimised sort for your platform? But on very, very tiny systems this might be unaffordable.

Anyway, C doesn't have Rust's core versus std distinction and so libc is a muddle of both the "Just useful library stuff" like strlen or qsort and features like open which are bound to the operating system specifics.