> As long as the unsafe parts are safe, you can rest assured that the safe parts will be safe too.
That is not true. It is possible to have two pieces of validated unsafe code that are "safe" in isolation but when you use them in the same codebase, create something unsafe. This is especially true in embedded contexts, where you are often writing code that touches fixed memory offsets, and other shared globals like peripherals.
In some cases you might have the excuse that, well, you did say on the tin not to do this with the unsafe element. For example if I use Bob's "I need exclusive control of GPIOs 2, 3 and 6" and also Kate's "I need exclusive control of GPIOs 1, 2 and 4" unsafe code, then it's my fault, they did both tell me this requirement and they clash.
But in general this is specifically a bug in the unsafe code. The Rustonomican is very clear that it's not the safe code's fault that your unsafe code doesn't work. In the scenarios with conflicting libraries I guess it's the fault of somebody who linked conflicting libraries, but it's definitely never the safe code.
That is not true. It is possible to have two pieces of validated unsafe code that are "safe" in isolation but when you use them in the same codebase, create something unsafe. This is especially true in embedded contexts, where you are often writing code that touches fixed memory offsets, and other shared globals like peripherals.