[steveklabnik]

> Fil-C now has support for inline assembly, so it's not needed anymore, and I believe indeed the intention is to remove it, since Fil-C is not supposed to have any unsafe hatches.

See, this is nuance! Nuance is good! But you can't go around saying "fil-c has no escape hatches" when it has one, even if that one is planned on being removed.

> Fil-C is not Linux only by design, that's completely false.

Can you explain to me how it would work on other platforms? It currently does not, and I don't see how it can. Or at least, not without more "escape hatches."

[mbrock]

It would work basically the way it works on Linux? What makes you think it's somehow fundamentally Linux-specific?

[steveklabnik]

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]

>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, you can see they clearly do change over time too.