It's not "how [you] talk". It's that you're not making an actual point. There is no "safety" threat here, nor is there an "infrastructural weakness[]". Fretting

It's not "how [you] talk". It's that you're not making an actual point. There is no "safety" threat here, nor is there an "infrastructural weakness[]". Fretting about "safety" without identifying a threat model is vacuous. What is, specifically, your threat model? What security guarantees can a program make only through bypassing libc? Why aren't the vast majority of programs --- the ones that call libc --- vulnerable to this ineffable threat? Users get to control how programs execute. They can interpose symbols. They can disassemble programs. They can run programs under a debugger. They can modify the kernel. They can run programs in a VM. A program can't detect this intermediation; nor does it have any right to do so. A program has no business breaking random OS visibility and control features. We generally call the ones that try malware. Bypassing libc when making system calls doesn't give a program any insurance against environmental changes. It just inconveniences users while providing no "safety" guarantees. If you want full control over a program's execution environment, ship an appliance.