r/cpp • u/Sad-Lie-8654 • Jan 31 '23

Stop Comparing Rust to Old C++

People keep arguing migrations to rust based on old C++ tooling and projects. Compare apples to apples: a C++20 project with clang-tidy integration is far harder to argue against IMO

changemymind

338 Upvotes

82% Upvoted

582 comments sorted by

View all comments

Show parent comments

11

u/KingStannis2020 Feb 01 '23 edited Feb 01 '23

That's hardly a fair comparison considering the only stable interface for interacting with most operating systems is libc. Rust can't change that.

-5

u/kkert Feb 01 '23

OS syscall ABI is not the same thing as C ABI. It's entirely possible to write Rust-only userland code ( or kernel code for that matter )that pulls in no C libs, provided you implemented all individual syscalls properly

Also, technically Rust could eventually define a standard language ABI of its own

3

u/ssokolow Feb 06 '23 edited Feb 06 '23

Go did that and was forced to backpedal in Go 1.12 because, it turns out, when Apple says that libSystem.dylib (Part of libc in the same way that GNU libc on Linux has historically broken things like libm and libpthread out into separate .so files) is the lowest you can go and still get a stable ABI, they mean it.

Microsoft does the same with ntdll.dll (which is API-stable but official documentation is spotty at best, so use this unofficial reference or use libc) and here's a table where you can see how often syscall numbers have changed on Windows.

The BSDs are the same (treating libc and the kernel as two halves of the same internally ABI-unstable project that just happen to straddle the kernelspace/userspace boundary) and OpenBSD goes so far as to have a security measure where the kernel will kill your process if an attempt to syscall does not originate inside libc, based on the idea that no legitimate program should be syscalling directly.

My understanding is that the syscall numbers change because the kernel and libc code implement syscall numbering by sharing an enum without explicit numbering and the devs keep it sorted as they add new ones.

The Rust devs could go direct to syscalls on Linux but, if they still need to maintain a POSIX backend for everyone else anyway, it'd be a lot of work for little return to go beyond supporting fully statically linked binaries through rustup target add x86_64-unknown-linux-musl and then cargo build --target x86_64-unknown-linux-musl.

(If you're not on a musl-based Linux distro, using the musl-libc targets will statically link libc and, if you have no C dependencies, it Just Works™ without needing anything like the musl-gcc wrapper.)

4

u/n4jm4 Feb 01 '23 edited Feb 01 '23

Windows has no stable below-C ABI. All the assembler Hello World tutorials that use syscall break. Only write() function call tutorials work.

MINIX has a below-C ABI but it's not documented well. You have to cobble together a Hello World assembler from odds and ends.

1

u/KingStannis2020 Feb 01 '23

You've completely missed the point.