Platform Dependencies of std

This page lists every function std imports from outside SultanC: the library it comes from, why that library is the platform's stable boundary, the C declaration it was checked against, and how mature toolchains handle the same boundary. It also lists what std implements in SultanC instead of calling the platform. It is written for contributors who add or port platform code, and for anyone auditing what a SultanC executable links.

The rule is the one Rust and Go follow. std depends only on the platform's supported system interface. It does not use a C runtime for language features such as memory copy, formatting, math, allocation, cryptography or DNS. Each import names its library at the declaration, in std, and the compiler holds no table of std's symbols.

How a declaration names its library#

[public] extern ["library"] def name(params): Result [= "link_name"];

"library" is the library as the target's loader names it: a PE DLL ("kernel32.dll"), a Mach-O install name ("/usr/lib/libSystem.B.dylib") or a WebAssembly import module ("wasi_snapshot_preview1").

= "link_name" binds the declaration to an exact linker symbol when it differs from the source name, for example = "stat$INODE64". It plays the role of Rust's link_name and of a C asm label. Both texts are nonempty and contain no NUL byte. External data (extern let x: T = "symbol";) takes no library.

A link name that exists on only some architectures goes behind a target guard (if (target.architecture == "x86_64") { … } else { … }). Darwin's $INODE64 names exist only on x86_64. The interpreter's extern table (tools/generate/generate_host_externs.py) must respect the same guard: linking stat$INODE64 on every macOS target would stop the compiler loading on arm64 Macs.

tools/audit/macos_imports_audit.py --sdk <MacOSX.sdk> --arch arm64|x86_64 <binary>… checks every import of a Mach-O executable against the SDK's .tbd exports for that architecture. dyld rejects a binary if any import is missing, and this check catches that without a Mac.

How the library reaches the binary#

The parser stores the library and the link name in the declaration (compiler/frontend/ast/declarations.sn: تصريح_دالة.المكتبة_الخارجية and اسم_الربط). Lowering carries them into MSIR as دالة_خارجية_مسير.الاسم (the linker symbol) and .المكتبة. Each target then uses them as follows.

The compiler names one library itself: LLVM's (LLVM-C.dll, مكتبة_إل_إل_في_إم_باسم_للهدف in compiler/backend/target/runtime_symbol_query_context.sn), because LLVM is a dependency of the compiler, not of std. Adding an extern to std never requires editing the compiler.

Calls and unsafe#

A raw kernel call (raw_kernel_call) must appear inside unsafe. A call of an external function does not need unsafe, by the owner's decision: an extern declaration is a typed signature, and std keeps its pointer arguments and results in bounded wrappers.

Linux, Android and FreeBSD: raw kernel calls, no libc#

std calls the kernel directly through raw_kernel_call. Linux and Android use library/std/os/platform/unix/linux/**, with syscall tables generated from each architecture's UAPI headers. FreeBSD uses platform/unix/freebsd, which shares the direct-kernel provider. Neither imports anything. This is Go's model: Go's syscall and runtime packages issue raw system calls on Linux and FreeBSD and link no libc, because both kernels guarantee a stable system-call ABI.

Kernel operations beyond basic file and process calls are in syscalls/operations.sn, with interpreter signatures. Their numbers are generated for every Linux ABI and for FreeBSD.

flock has an interpreter signature of two integers, and the two signal calls are marshalled like clone and waitid. The UAPI generators supply SIGPIPE, SIG_BLOCK and SIG_SETMASK (1 and 3 on MIPS and FreeBSD, 1 and 4 on SPARC), LOCK_SH/EX/NB/UN, EAGAIN, EPIPE, AF_UNIX, O_EXCL, O_RDWR, the size of the kernel's sigset_t (8 bytes; 16 on MIPS and FreeBSD) and of sockaddr_un's sun_path (108; 104 on FreeBSD). Child stdio uses the existing pipe2 and ppoll operations. Unix domain sockets need no dedicated call: socket(AF_UNIX, ...), bind, connect, accept4, sendto, recvfrom and the name calls take a sockaddr_un built by os/unix_socket.sn.

Writing to a child's input without SIGPIPE#

A write to a pipe can raise SIGPIPE, which would end the process when the child has closed its input. Sockets avoid it with MSG_NOSIGNAL (Linux, FreeBSD) or SO_NOSIGPIPE (macOS); pipes have neither. Rust's std ignores SIGPIPE for the whole process and resets it in each child before exec. std instead blocks SIGPIPE in the calling thread for the one write and, after EPIPE, takes the pending signal with a zero-timeout sigtimedwait, as PostgreSQL's libpq does for its socket writes (pq_block_sigpipe, pq_reset_sigpipe). No process-wide signal state changes, and a child inherits nothing.

macOS: libSystem#

Apple does not support direct system calls: the syscall ABI is private and changes between releases. libSystem (/usr/lib/libSystem.B.dylib, which re-exports libsystem_kernel, libsystem_c, libdyld and others) is the stable boundary. Go has gone through libSystem on darwin since Go 1.12, and Rust's std links it through the libc crate. std names it on every declaration, as Go does.

The signatures were checked against the macOS SDK headers. On both Darwin ABIs, mode_t is u16, off_t and ssize_t are i64, size_t is u64 and socklen_t is u32. All modules below are under library/std/os/platform/unix/apple/darwin/.

Darwin ABI details#

• x86_64 inode ABI. std reads the 64-bit-inode struct stat (144 bytes) and struct dirent (d_namlen u16 at offset 18). On x86_64 the plain stat, opendir and readdir are the legacy 32-bit-inode functions, which <sys/stat.h> and <dirent.h> map to stat$INODE64, opendir$INODE64 and readdir$INODE64 (__DARWIN_INODE64, __DARWIN_ALIAS_I). The declarations are bound by link name under an architecture guard, as Rust's libc does. arm64 uses the plain names.
• struct addrinfo field order. Apple's <netdb.h> uses the BSD order: ai_canonname comes before ai_addr, the reverse of glibc. std's record follows the Darwin order. Reading the address from ai_canonname would fail every lookup, because that field is NULL without AI_CANONNAME.
• One declaration per function. Each libSystem function is declared once: close in file_descriptors.sn (used by sockets.sn), and mmap, mprotect and madvise only in virtual_memory.sn.

Windows: system DLLs, no CRT#

The Win32 API in the system DLLs is the supported boundary on Windows. The NT syscall numbers are private. std links no C runtime: there is no mainCRTStartup, and no memcpy, malloc or printf. The DLL is named at each declaration, as Rust's std does through windows_targets::link!.

Signatures were checked against the MSDN declarations. BOOL and int are i32; DWORD, UINT and ULONG (also u_long, since Windows long is 32-bit) are u32; HANDLE, SOCKET, SIZE_T and the pointer types are 64-bit; and LARGE_INTEGER is an i64 passed by value or by pointer. Modules are under library/std/os/platform/windows/.

kernel32.dll#

Other DLLs#

WASI preview 1#

WASI preview 1 is the system interface of a wasm32-wasi module. Every function is imported from the module wasi_snapshot_preview1, as Rust's wasi crate does with #[link(wasm_import_module = "wasi_snapshot_preview1")]. Signatures follow the witx definitions: handles, sizes and pointers are u32 on wasm32, flags are u16 or u8, offsets and rights are u64, and every function returns errno as i32. Modules are under library/std/os/platform/wasi/preview1/.

WASI has no permission bits, working directory, processes, pipes, unconnected sockets, file locks or Unix domain sockets. Those std functions report ENOTSUP (58).

What std implements in SultanC#

None of these call the platform.

A grep confirms that no libc or CRT language function is imported. Among the externs declared under library/, none is memcpy, memmove, memset, memcmp, strlen, strcmp, printf, snprintf, puts, malloc, calloc, realloc, free, sin, cos, sqrt, pow, exp, log, floor or fmod, and none comes from a C runtime DLL (ucrtbase, msvcrt, vcruntime).

grep -rnE '(خارجي|extern)' library | grep -wE 'memcpy|memmove|memset|strlen|printf|malloc|free|sin|cos|sqrt|pow'

The command prints nothing. The import tables of built examples agree: a Windows executable imports only kernel32, ws2_32, crypt32, shell32 and bcryptprimitives functions.

Dependencies outside std#

Two dependencies remain outside the rule above, and neither is std.

• The C Stage0 bootstrap compiler (bootstrap/) is a C program. The Stage1 it produces uses the host C library (malloc, memcpy); Stage2 and later stages do not.
• The compiler's LLVM provider imports the LLVM C API (compiler/backend/provider/llvm/ffi), including LLVMBuildFPExt, LLVMBuildFPTrunc and the LLVMBuildFPToSI family, and uses the llvm.fptosi.sat and llvm.fptoui.sat intrinsics.

Limitations#

• shell32.dll's CommandLineToArgvW could be replaced by SultanC code, which would remove that import.
• ve-linux-gnu has no std OS layer; see Targets.
• Applications can still request libc through -l c on ELF targets, but std itself never does.

See also#

• Targets: the target matrix and how each target is linked and verified.
• Concurrency: the wait/wake and thread layers built on these calls.
• MSIR and code generation: how declarations reach the backends.
• Standard library coverage: what std provides on top of these interfaces.