In some cases we don't want safety. C can be safe or unsafe depending on how you approach a problem.
See http://static.rust-lang.org/doc/master/rust.html#unsafety
Nothing new in software development. All the "new" shinies are decades (!) old.
I wonder how we got sidetracked like that.
1. Performance reasons. For example: zero copy data structures, mutable data structures, controlling data locality.
2. Direct memory mapped hardware access. For example: device drivers, kernel, embedded systems, microcontrollers.
3. Bitwise and machine specific conversions. For example: endianess conversions.
4. Structure type coercion. For example: object systems, tagged data structures etc.
Whereas in C there is no way to distinguish between unsafe and safe code.
Of course doing this usually means your code isn't portable, sometimes not even to other versions of the same compiler. I often wish C had a defined order for bitfields, for example.
One of the things I do to help debug & test embedded code is to factor out code which isn't dependent on the hardware platform (eg communication protocols) into a library, and compile it for, and write test programs to test them on, the host. So even embedded code is often best written to be as portable as possible.
#leaves to check some old code
.
.
.
#comes back
Apparently my younger self knew what he was doing. ( The conversion is done correctly :shocked: )
"In fact, C may be part of the problem: in C it's easy to make byte order look like an issue. If instead you try to write byte-order-dependent code in a type-safe language, you'll find it's very hard. In a sense, byte order only bites you when you cheat."