Not really. We can simply expand it to "All code has bugs", and then we're simply at Rice's theorem. In C, the class of bugs that can not be proven to not exist are also quite dangerous - remote code execution, as an exemplar consequence. In rust, you're limited to a program that can crash, or that has other semantic faults.

So it's clearly not wrong, and is actually a totally well established idea well outside of the context of rust or C.

An 8-bit AVR executes instructions from on board flash memory that requires twiddling hardware lines to erase and rewrite.

Remote code execution isn't a concern.

AVR ATMega is self programmable ie a bootloader can re-flash it if its configured to allow but you would need some code already resident on the flash to allow, it couldnt be done without this code.

No, but memory corruption related to pointers misuse or unsigned arithmetic is.

(I think you mean signed arithmetic here and in your almost-sibling comment.)

Probably, I always mix them up.

You can very easily have all the sorts of memory unsafety you have in C, in Rust.

Only in sections marked as unsafe.

In C every single line of code that manipulates pointers, does string operations, uses arrays or unsigned arithmetic is a possible cause of memory corruption.

Most code is less-than-perfect, independently of language. But the consequences of this depends on the language.

IMHO There's a big gap between perfectly written and poorly written

Not poorly written, just it's very easy to forget things, and even very well-written, readable, documented C code usually has memory-related bugs, as long as it's written by fallible humans. Nearly every networked C program in existence has had a buffer overflow CVE at some point - that's simply not possible in Rust.

Corrrections welcome, but I think there is one buffer that you can overflow in every Rust program: the stack.

If you have a MMU, the runtime will/should protect against that by mapping a page as 'trap on write' and panicking/rebooting/signaling if you do, but if you don't, I don't think rust has any functionality to prevent it.

Or can you declare that your stack is x bytes, and have the compiler verify that no call chain will need more? (That typically would prevent the use of recursion, but that's not too bad)

The answer is basically "stack probes", yes.

I find very few relevant hits on that on Google (stack probes apparently also are hardware to measure various quantities such as moisture in stacks of materials), and none that explain to me what they are (you can enable them in gcc and Microsoft's compilers, and rust should use them instead of stack overflow checks, but that's about it), but from what I guesstimate, they are runtime instrumentation, not anything that a rust compiler could do to guarantee that a compiled and linked program never overflows the stack.

Can you tell me more about them?

They're runtime checks, but they're inserted by the compiler at compile time. So yeah, if you link in code that wasn't compiled with them, then that code isn't protected.

You're right that a summary seems hard to find; http://www.delorie.com/gnu/docs/gcc/gccint_124.html has some decent stuff in it, but given that it's random GCC docs, the details may not be 100% accurate today, I dunno, I'm on a flight layover right now, so that's all I've got at the moment :)

They're dynamic checks.

Static checks for stack overflows are infeasible.

They are not infeasible, if you are willing to limit what your language can do.

Doing so doesn’t remove all useful programs, as the first Fortran compilers showed (they used a fixed addresses for all variables, be they local or global (that they did not support recursion is not that surprising, given that many CPUs of the time didn’t have a return stack))

That’s why I asked whether Rust supported such a thing. It would be very helpful, for example, if your build system would tell you that that difficult to test error handler would, if called, overflow the stack before you spent time and, possibly, lots of money, on trying to run it.

> That typically would prevent the use of recursion, but that's not too bad

It also prevents the use of indirect calls/virtual functions, because they can hide recursion. That's Bad.

It's fairly trivial to overflow a buffer in Rust. I don't consider having to write "unsafe { /* overflow buffer code goes here */}" non-trivial.

The difference is that when you are forced to declare where your program does not follow some safe semantics, while it's still trivial to write an overflow, it's also trivial (or at least not nearly as complex as some alternatives) to find and fix, compared to a language where the entire code base is a possible source for those problems.

For comparison, I would say C and C++ (but to a slightly lesser degree) are also trivial to write buffer overflows in, it is definitely non-trivial in many cases to find and fix those problems, as the surface area is so large.

To illustrate this, it's trivial to write a buffer overflow in almost all languages that provide any sort of raw memory access or hardware instructions (ASM), even if through a module. It's trivial for me to create a buffer overflow in Python or Perl my including a module that allows direct assembly code access. The difference when using those languages is that when I run into a buffer overflow problem, I can be reasonably sure it's in a place where I bypassed the assurances provided by those languages, or in some included module that did the same (including just using a shared library). When tracking down a problem like that, I'll focus my attention on those spots, which makes identifying and hopefully fixing those problems easier.

Rust's "unsafe" is really an in-language way to provide a similar set of levels of assurance about how likely the code is to have problems of specific types, with assurances provides by the language and compiler. This is a step above what C and C++[1] provide, and thus welcome.

1: C++ provides some similar assurances based on types, but by nature of how "safe" code becomes "unsafe" when used in conjunction with unsafe portions, is much harder to assess at a block level, since you can't even be sure a line is safe until you've verified all the types used within it.

For embedded code, I'd recommend that all application code should be compiled with the `--deny unsafe-code` option. Then the compiler will stop you. A separate module for the I/O code providing is the only place where one should use `unsafe`. Extra care must be taken here, in code review and in testing.

Do you have any idea how impossible it is to do anything useful without unsafe in Rust on a microcontroller?

About as hard as on desktop? I mean, many of the core datastructures commonly used there are implemented using unsafe. This does not mean that the application code must or should be riddled with unsafe code blocks... For a very simple example see https://github.com/hackndev/zinc/blob/master/examples/blink_...

If Ada, Pascal and Basic can, so can Rust.

Every case where this is not true is a bug.

You can also get a buffer overflow in Python and Java by abusing their equivalents of "unsafe".

"unsafe" in Rust isn't abuse. It's explicit syntax with compile time effects specifically for the purpose of facilitating unsafe constructs, like direct memory buffer manipulation, required for low level programming.

I've never tried the Python or Java equivalents and frankly don't know enough about them to even know whether your comment is accurate or not.

Java has `sun.misc.Unsafe`, and Python has the FFI which is remarkably easy to misuse. The point is that you don't use these unless you need to, and you spend special effort when you do - same as `unsafe` in Rust. The rest of your code runs perfectly safely, and the vast majority of code has no need to use `unsafe`. Code which uses `unsafe` and isn't obviously either directly an FFI wrapper or a straightforward implementation of a generic data structure is generally considered bad form.

True that unsafe isn't considered too wrong in rust, but auditing the small amount of unsafe code is much easier than all the code.

Is getting that past the person who is reviewing your code also trivial?

Possibly. Depends on the quality of the reviewer and the complexity of the code (as a whole). On average Rust programmers aren't necessarily better than programmers using any other language. If history is a guide then if Rust takes off there will be plenty of terrible, buggy, unsafe and very thoroughly reviewed Rust code out there used in popular, widely used applications or services.

I find the notion that "explicit unsafe makes bugs less likely" to be suspect. It seems reasonable, almost tautological at first glance. But theory and practice are different animals.

It certainly is possible in Rust. Rust is not memory safe.

As it is in any language that has FFI to Assembly.

But that is a big difference in the amount of unsafety per line of code.