It's not a very good impression: MISRA C is basically a list of guidelines, half of which say "don't invoke undefined behaviour" (duh) and the other half are questionable coding-style rules. None of it really corresponds to any Ada features (not to mention you basically ignore any MISRA rule you like if you just write down that you've done it and attempt some justification).
The goal of MISRA C mostly isn't to prevent problems in your code. It's to make the code more amenable to static analysis, which _can_ detect problems.
Which, notably, is what Rust does by construction: you don't have to do (much) alias or escape analysis against Rust, because it's given to you by the compiler for free.
There's also been a decent amount of empirical research on MISRA C's effectiveness, most of which has shown that attempting compliance actually makes programmer-introduced faults more likely[1].
It's extremely common to use MISRA without static analysis (I would personally advocate for the opposite way around). Also, if the goal is to make static analysis easier, why not just have the rule be 'the static analyser must be able to say this is OK'? (which will depend greatly on what the capabilities of your static analyser are).
MISRA: Of course the C language provides loads of standard library functions which look ordinary but are actually defined in a way that's hideously dangerous. You can use most of those but please take care to avoid mistakes (MISRA D4.11).
Ada: It would be insane to provide a standard library full of dangerous sharp edges so we didn't do that.
You need Ada or other languages for that.