4 ms·
On non-Linux platforms, you must go through a system provided shared library rather than make syscalls directly. fil-c has its own ABI, and so it has its own li
by steveklabnik 2mo ago
On non-Linux platforms, you must go through a system provided shared library rather than make syscalls directly. fil-c has its own ABI, and so it has its own libc that uses it. You cannot recompile those other systems's libc (or equivalent) with fil-c, therefore, the strategy used on Linux cannot work.
This is one reason why Rust has unsafe: you have to interact with inherently unsafe APIs in order to do anything meaningful with the operating system. fil-c needs an equivalent of some kind, and so isn't better or worse here, it's just the reality of how these systems work.
- landr0id 2mo ago>you must go through a system provided shared library rather than make syscalls directly Just to add to this, on Windows for example you're really only supposed to invoke syscalls via ntdll as the syscall table is not stable so their numbering changes over time. You cannot guarantee forward or backward compat if you do not use the library. If you look at some of the syscalls in https://github.com/j00ru/windows-syscalls https://github.com/j00ru/windows-syscalls, you can see they clearly do change over time too.