Hacker News Reader

Comment by remexre | Hacker News Reader

Rust uses the C compiler as a linker, because this is often the only way to ensure all the libraries needed by the system toolchain are included. (Compare to the CCLD variable in autotools -- it refers to the command to use the C compiler as a linker, and exists for this very reason.)

This isn't only libc -- it also includes libgcc (or compiler-rt, depending on your system toolchain), which, despite the name, may still be called "behind your back" by the LLVM toolchain.

> So it's a Rust program but it's just calling inline assembly and using a C compiler?

Yeah, I think this article is more in the tradition of [0] (but trying hard not to drop rustc) than being completely practical advice on making the binary you ship to users smaller.

[0]: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

View on HN

Well, not quite -- https://github.com/grahamking/demeter-deploy/blob/master/see... is the Rust version of a program that used to be written entirely in assembly, and it seems that it ends up being the same size. There's a few bits of asm in amongst the Rust, but it's still definitely a Rust program.

800 lines of ASM file reduced to 600 lines of Rust, including comments and constants in both cases. He might be pushing the limits, and everything's unsafe Rust, but unsafe Rust is still safer than raw assembly.

> unsafe Rust is still safer than raw assembly

I don't think I would go that far. Assembly doesn't have undefined behavior, and especially not with the strict constraints around references as in Rust. The safe/unsafe dichotomy in Rust is better than only using C or C++ when there are concise, robust encapsulations around broken invariants.

> Assembly doesn't have undefined behavior

Certainly some assembly languages do.

Which ones? I assume at least the 1:1 machine code kind doesn't, and you mean something more like bytecode, but it'd be interesting if I'm wrong on that count.

> I assume at least the 1:1 machine code kind doesn't

They do, because the machine code sometimes has undefined behaviour. E.g. on the 6502 famously 1/4 of the instructions are undefined (all of the 0b.....11 ones), and many of them behave differently on different implementations of the processor (up to and including halting it, or placing it in a strange state).

Most of those undocumented instructions are what in C would be called "implementation defined behaviour" and have properly defined results, they might just differ between specific CPU models. There's only a very small number of unstable instructions which have unpredictable results (caused by "cross talk" due to incomplete instruction decoding).

Halting the CPU would also generally have to be modelled as undefined behaviour in the standard.

The 6502 has one (or some?) "illegal" instructions where the effects are unpredictable. Only case I can think of though.

> I don't think I would go that far. Assembly doesn't have undefined behavior

As someone who has written a fair amount of assembler over the years... Yes, it doesn't have undefined behavior, but it also lacks practically all guard rails and safeties.

The smallest error and you might do things like completely messing up your call stack – just need to forget one "POP" or mess up with stack pointer adjustment. Or for example a computed jump in the middle of an instruction.

You can create bugs that can be almost impossible to figure out from a crash dump that even something as low level as C will effectively protect you from doing.

I wonder if those issues can't be somewhat mitigated with a linter or interactive emulator. In any case, I think assembly is more uniformly difficult (and not portable!), while unsafe Rust generally feels less painless but you might have no idea which invariants you need to enforce unless you're very knowledgeable. Definitely don't write a whole application in either!

You could also say it doesn't have defined behavior.

Reply on news.ycombinator.com