> The source was the fact that dynamically allocated memory in C is not bounds checked. When you say "bounds-checked", what are you talking about? To me, it m

> The source was the fact that dynamically allocated memory in C is not bounds checked. When you say "bounds-checked", what are you talking about? To me, it means that "x[somenumber]" make the program abort if somenumber is out of range. However, as you can see, the reads and writes were never out of range. As I see it, the issue is that uninitialized memory is being read. This is not "unsafe", cause it will never crash your program. I don't know the exact definition of "undefined behaviour", but since we are using a custom allocator, even if reading from freshly malloc'ed memory is undefined, it may not be in this case. Rust doesn't let you get uninitialized memory without using "unsafe", so to construct a program with the issue, he had to reuse the buffer. I think it's a lot less likely to happen with Rust, since it is visible to anyone that it is the same buffer. > If he had ignored the custom allocator and used the defaults in both languages (e.g. malloc in C, whatever it is in Rust) How do you know the default allocator isn't using memory that was previously used for the private key? And why do you think the default allocator wasn't used in the Rust code? PS: Taint analysis also has a much better chance of working in Rust, since we are not working with libraries, but standard language constructs. In C, your taint analysis would have to taint every byte straight from malloc.