3 ms·
> with exception of C and C++ with their direct dependency on POSIX related APIs ...why would POSIX be special if the POSIX layer is statically linked with the
by flohofwoe 3y ago
> with exception of C and C++ with their direct dependency on POSIX related APIs
...why would POSIX be special if the POSIX layer is statically linked with the application and would just be a translation layer to anything that lies below? Same way MUSL works on Linux as alternative C library which bypasses glibc and instead directly uses syscalls to talk to Linux.
(also technically the POSIX standard doesn't have anything do to with the C and C++ standards)
- lmz 3y agoThe POSIX standard definitely has something to do with C standards: > Parts of the ISO/IEC 9899:1999 standard (hereinafter referred to as the ISO C standard) are referenced to describe requirements also mandated by this volume of POSIX.1-2017. Some functions and headers included within this volume of POSIX.1-2017 have a version in the ISO C standard; in this case CX markings are added as appropriate to show where the ISO C standard has been extended (see Codes). Any conflict between this volume of POSIX.1-2017 and the ISO C standard is unintentional.
- flohofwoe 3y agoWell ok, the two standards are overlapping where it makes sense, I stand corrected there. But nothing prevents me from writing C or C++ programs on Windows which don't have a single POSIX (or even libc call) in them, but exclusively use Windows system DLL calls - and those are still entirely valid C or C++ programs (although I'm aware that the situation is muddy for some libc calls which some compilers treat like builtins, e.g. memset and memcpy).