Comment by Animats

Comment by Animats 2 days ago

The article doesn't address the hard problem of figuring out array sizes. There's some work going on as part of the DARPA TRACTOR program to work on that. This area, of course, is the usual cause of buffer overflows.

The goal is to convert C pointers to Rust arrays, pointer arithmetic to Rust slices, and array allocations to Vec initialization. The hard problem is figuring out the sizes of arrays, which is going to require global analysis down the call chain.

If you're going to publish papers on this, please address that problem.

uecker 2 days ago

Of course, one you have identifies the bounds to each pointer you could just do bounds checking in C.

Reply View 14 replies

AlotOfReading 2 days ago

That's not actually sufficient in the general case where the pointer may not be the type of the underlying object. You also have to respect strict aliasing even if the bounds are correct. This isn't true in the same way in Rust because memory is untyped. You only need to ensure basic memory validity (range, initialization, alignment, etc).

Reply View | 13 replies
- uecker 2 days ago
  
  Yes, you also do not want to do random casts, but this is even easier. I do not get your point out memory validity in Rust. What if you write where a pointer is stored, or even a boolean?
  
  Reply View | 9 replies
  
  AlotOfReading 2 days ago
  
  I'm talking about type punning specifically here. There's a lot of old C code out there that stores everything in int * buffers and casts pointers back to the correct type. I'm even aware of one toolchain for a widely used MCU that typedef'd char to int (i16).
  I believe this would be legal in Rust today if you respected the other rules, with the caveat that it wouldn't be remotely idiomatic or possible without unsafe.
  
  Reply View | 8 replies
- zozbot234 2 days ago
  
  Rust has pointer provenance which implies very similar constraints to the "typed memory" wording of C/C++.
  
  Reply View | 2 replies
  
  AlotOfReading 2 days ago
  
  Does it? It's very unclear to me whether something like type punning is prohibited by provenance today. The docs don't provide much clarity, and the comments I can find by ralf suggest the details are undecided. I can't imagine it won't be eventually prohibited since we already have hardware designs prohibiting it and it's a terrible code pattern to begin with, but I don't know if the language currently does so.
  
  Reply View | 0 replies
  
  steveklabnik 2 days ago
  
  This isn’t correct. Just because Rust has aliasing rules doesn’t mean they’re the same sorts of rules.
  C and C++ are also looking to adopt more formal provenance rules.
  
  Reply View | 0 replies