std: move os/darwin.zig and related to c/darwin.zig
Move to c/darwin.zig as they really are libSystem/libc imports/wrappers.
As an added bonus, get rid of the nasty usingnamespaces which are now unneeded.
Finally, add os.ptrace but currently only implemented on darwin.
Hey, just a note in case it would change your definition for os.ptrace - On Linux, it seems the fourth argument to ptrace is a pointer-sized type, as it can be used as an address or a bitmask (my attempt was here: https://github.com/ziglang/zig/pull/14839)
Hey, just a note in case it would change your definition for os.ptrace - On Linux, it seems the fourth argument to ptrace is a pointer-sized type, as it can be used as an address or a bitmask (my attempt was here: #14839)
I'll let @andrewrk decide how to go about doing this. This PR doesn't conflict with his addition of ptrace for Linux which is exposed only in os/linux.zig so we can could merge this one as-is and then roll out another PR after Andrew merges his to fix the signature ptrace.
I like the idea of moving "must link to c" to a dir with name c. However, mixing error abstractions with mere bindings feels inconsistent to os/windows.zig, which only has error abstractions and data.
If we go that route of mixing bindings + error abstractions, then I would favor keeping the error abstraction next to the binding or file reference to the binding unless we abstract over multiple OSes.
Any thoughts? I'm also asking to have a clue how I should (re)structure my PR #14726.
I think Windows is a little special as there are many layers the user can opt into: use kernel32 or use only ntdll. For Windows we also want to implement kernel32 wrappers ourselves where possible, while in case of macOS, os.zig is the closest to it where we would only implement things like posix_spawnp or execveZ_expandArg0 or whatnot. Additionally, note that macOS bindings mirror what we do for BSDs already, and all Darwin-specific interfaces are still available via std.os.darwin. Finally, I don't see any point in moving the error bindings into a different file, at least not yet - these bindings are incredibly specific to macOS as they are used to interface with the Mach kernel from the user-space. What this PR offers works pretty well already - have a look at changes in https://github.com/kubkon/zdb/compare/start-with-fork
Andrew has merged his parallel builds branch adding more goodies including raw ptrace syscall wrapper on Linux, so here's my plan. I will merge this as-is, and then while adding HCS PoC for macOS, I will try to add a draft os.ptrace wrapper that works on both linux and darwin.