3 ms·

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

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 1y ago
Of course, one you have identifies the bounds to each pointer you could just do bounds checking in C.
- AlotOfReading 1y 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).
  - uecker 1y 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?
    - AlotOfReading 1y 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.
      - steveklabnik 1y ago
        Rust does not have strict aliasing, that’s correct.
        uecker 1y ago
        But Rust still has trap representations, or? In practice, this implies similar constraints as strict aliasing.
        steveklabnik 1y ago
        That’s a related concept but not the same thing. The “validity” rules in Rust (like C’s trap representations) are about which bit patterns represent valid values, not about which pointer types may alias the same memory. Strict aliasing is a type-based access rule; validity is a value-based representation rule. Rust enforces the latter (invalid values are undefined behavior), but explicitly does not enforce the former (raw pointers may alias arbitrarily). That’s the difference. To put it into code: float foo(const uint32_t *xs) { const float *fp = (const float*)xs; // UB: incompatible effective type But in Rust, the equivalent: fn foo(xs: *const u32) { let ptr = xs as *const f32; // not UB to access through ptr later (I am on my phone and so may have made small errors and revised a few times, my apologies.) It’s also true you must pay attention to validity: this works in Rust because all bit patterns of u32 and f32 are valid for f32 (IEEE-754). If you tried u32 -> bool, you’d hit UB not because of aliasing, but because many u8 patterns are invalid for bool (only 0 and 1 are valid). Creating the pointer is fine; dereferencing would only be okay if you first ensure at runtime that the stored bits are valid for the target type, and alignment is satisfied.
        uecker 1y ago
        I understand the difference and this is why I said "similar constraints". Once you have non-value (trap) representations you need to be careful when dereferencing pointers cast to different types, even if you do not have strict aliasing. The point under the discussion upthread was that in unsafe Rust this would not be a problem because it does not have strict aliasing and my argument that it still is would be because of non-value representations.
  - zozbot234 1y ago
    Rust has pointer provenance which implies very similar constraints to the "typed memory" wording of C/C++.
    - AlotOfReading 1y 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.
    - steveklabnik 1y 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.

uecker 1y ago

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

AlotOfReading 1y 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).
- uecker 1y 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?
  - AlotOfReading 1y 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.
    - steveklabnik 1y ago
      Rust does not have strict aliasing, that’s correct.
      - uecker 1y ago
        But Rust still has trap representations, or? In practice, this implies similar constraints as strict aliasing.
        steveklabnik 1y ago
        That’s a related concept but not the same thing. The “validity” rules in Rust (like C’s trap representations) are about which bit patterns represent valid values, not about which pointer types may alias the same memory. Strict aliasing is a type-based access rule; validity is a value-based representation rule. Rust enforces the latter (invalid values are undefined behavior), but explicitly does not enforce the former (raw pointers may alias arbitrarily). That’s the difference. To put it into code: float foo(const uint32_t *xs) { const float *fp = (const float*)xs; // UB: incompatible effective type But in Rust, the equivalent: fn foo(xs: *const u32) { let ptr = xs as *const f32; // not UB to access through ptr later (I am on my phone and so may have made small errors and revised a few times, my apologies.) It’s also true you must pay attention to validity: this works in Rust because all bit patterns of u32 and f32 are valid for f32 (IEEE-754). If you tried u32 -> bool, you’d hit UB not because of aliasing, but because many u8 patterns are invalid for bool (only 0 and 1 are valid). Creating the pointer is fine; dereferencing would only be okay if you first ensure at runtime that the stored bits are valid for the target type, and alignment is satisfied.
        uecker 1y ago
        I understand the difference and this is why I said "similar constraints". Once you have non-value (trap) representations you need to be careful when dereferencing pointers cast to different types, even if you do not have strict aliasing. The point under the discussion upthread was that in unsafe Rust this would not be a problem because it does not have strict aliasing and my argument that it still is would be because of non-value representations.
- zozbot234 1y ago
  Rust has pointer provenance which implies very similar constraints to the "typed memory" wording of C/C++.
  - AlotOfReading 1y 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.
  - steveklabnik 1y 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.