OS function names
=================

There are some functions that SLUL probably shouldn't provide,
such as those in libm on POSIX systems:

    double sin(double x);
    float sinf(float x);
    ...

But we still want to have slul-friendly names of those:

    func .sin(float x) -> float
    func .sin(float32 x) -> float32
    ...

Also, we don't want to have any system-specific stuff in the
interface files! And some systems might not even need any special
handling for these functions.

But, normally, the names of these would then be:
(TODO reserve Float/Int/etc. as type names)

    Float_sin
    Float32_sin

Solution 1: Have a system-installed mapping file
------------------------------------------------

E.g. /usr/share/slul/system/elf_posix.mapping:

    Float_sin       acb123def456ghj789...   sin
    Float32_sin     987zyx654wvu321tsr...   sinf

     ^-- from name      ^-- funcdef hash     ^-- to name

Perhaps this should be per "userabi" instead, and use the multi-arch triple:

    /usr/share/slul/system/userabi_gnu.mapping
    /usr/share/slul/system/userabi_musl.mapping


Solution 2: Hard-code these in the compiler
-------------------------------------------

This means that they can't be overridden without a re-compilation.


Problems (with both solutions)
------------------------------

If new ones are added to the interface file without adding them to
the mapping, then they will be compiled with the wrong name (and
generate a load-time error).

Another issue is that binaries become locked to a specific
user-ABI/system/libc. This includes modules of library type also!