"fringe platforms which can't even run a Rust compiler" [LWN.net]

"fringe platforms which can't even run a Rust compiler"

Posted Feb 14, 2021 0:20 UTC (Sun) by sthibaul (✭ supporter ✭, #54477)
In reply to: "fringe platforms which can't even run a Rust compiler" by Cyberax
Parent article: Python cryptography, Rust, and Gentoo

> just do "#include <socket.h>" and then pre-process the file.

Yes, but that still doesn't magically collapse all the typedefs. With just socket.h that produces 500 lines of C, that a C compiler and scripts shared by *all* ports would much better grok than doing seds by hand.

> For example, Rust has special definitions to navigate the socket headers (these are macros in C, not functions).

Ok, but that's only a very tiny part of the Posix interface.

> C also doesn't specify the error returns.

You mean the set of errors that a function may return? Yes, and a kernel never makes such a promise as the exact set of errors it might ever return in the coming decades.

> > Why Rust?
> Because it's safer than C and faster to write.

Let me rephrase: why Rust in particular? And not the myriad of other languages that have been invented by mankind?

> > Really, that's exactly the point: it looks like Rust people want to bring the whole world into Rust, and not bother with the rest of the world that isn't Rust.
> Honestly, that would be a great outcome for the world.

So that's exactly what I wrote in another comment: so much for the free software dream, if you're free to use any language, as long as it is Rust.

to post comments

"fringe platforms which can't even run a Rust compiler"

Posted Feb 14, 2021 16:05 UTC (Sun) by nix (subscriber, #2304) [Link]

> Yes, but that still doesn't magically collapse all the typedefs. With just socket.h that produces 500 lines of C, that a C compiler and scripts shared by *all* ports would much better grok than doing seds by hand.

Aha, thank you for giving me another use case for CTF! The upcoming CTF format v4 work will include an objdump option that emits a collection of C header files given a .ctf section. They won't be the same as the inputs, of course (no comments, for starters, and with the default linker options you'll get one big header for non-ambiguous types and then small headers #including the big one for all the ambiguously-defined ones), but it'll be better than nothing -- but until now I didn't have an answer for why this would ever be better than using the original .h files. Now I have one: transformations on the headers to help people doing work like this. (A transformation that collapses away all typedefs, leaving everything textually defined in terms of the base types, and leaving the typedefs around but with no actual users, should be trivial to implement. It's probably a bad idea to *use* those headers, but for human analysis for FFIs it's probably likely to be useful.)

"fringe platforms which can't even run a Rust compiler"

Posted Feb 15, 2021 0:28 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> Ok, but that's only a very tiny part of the Posix interface.
You actually don't need much to bootstrap Rust. The now-removed CloudABI was about 500 lines of code for the libc, which is probably about the minimal amount.

> Let me rephrase: why Rust in particular? And not the myriad of other languages that have been invented by mankind?
For stuff like libc you need a language that has no runtime (no GC, no threads created behind your back, etc.), natively compiled, memory-safe and preferably with additional type-safety-enforced guarantees.

Not many languages fit this bill. Out of modern-ish ones only Rust and Swift fit the bill.