4 ms·

Rust can easily produce C compatible symbols.

by nynx 5y ago

matheusmoreira 5y ago
Yes, but the benefits of Rust won't extend beyond those symbols. Also, certain features of Rust that have no C equivalents cannot be exported. Will the gains in safety be contained entirely inside the modules that are written in Rust?
- nynx 5y ago
  Yes.
- Flex247A 5y ago
  From my experience, absolutely.
- oconnor663 5y ago
  > certain features of Rust that have no C equivalents cannot be exported Right, only "repr(C)" types can show up in "extern" APIs. So no data-bearing enums, no Vec<T>, etc. > Will the gains in safety be contained entirely inside the modules that are written in Rust? I think for some things the answer is yes, and for other things the answer is no. If the issue is that callers might retain some pointer or descriptor longer than they should, leading to a use-after-free or something like that, then there's probably no way to fix that with an API-compatible Rust reimplementation. What safe Rust would prefer to do is either 1) force explicit lifetime constraints on the caller or 2) replace the pointer/reference with some sort of smart pointer, which can either keep its referent alive or at least safely detect the fact that the referent is dead. But of course a C-compatible API has no way to represent (1), and (2) would presumably be an incompatible API change, so the Rust reimplementation can't really solve this issue. (Though if both Rust and C APIs get exposed for the new code, then new Rust callers could benefit from (1).) On the other hand, if the issue is that the caller might pass in some invalid indexes or other metadata, leading to an out-of-bounds array access within the module, Rust can help quite a bit. If the array in question is actually owned by the module (and not just a raw pointer to unknown memory) then bounds checking is required one way or another (unless it's either optimized away or explicitly skipped with unsafe code), and a Rust reimplementation will probably not suffer from out-of-bounds issues. Raw pointers into the caller's memory are harder to check, but even there if they can be converted to a safe slice immediately inside the API boundary, some subset of out-of-bounds accesses can still be caught. Looking at these two different kinds of bugs, I think it's interesting to think about what "inside the module" means here. In both cases, the UB we want to prevent (either use-after-free, or an out-of-bounds access) is "caused" by the caller's mistakes outside the module, but "occurs" on lines of code inside the module. In the first case, Rust can't protect itself against a bad (C) caller, but in the second case it might be able to.

Rust can easily produce C compatible symbols.

by nynx 5y ago

Rust can easily produce C compatible symbols.

Yes, but the benefits of Rust won't extend beyond those symbols. Also, certain features of Rust that have no C equivalents cannot be exported. Will the gains in safety be contained entirely inside the modules that are written in Rust?

nynx 5y ago
Yes.
Flex247A 5y ago
From my experience, absolutely.
oconnor663 5y ago
> certain features of Rust that have no C equivalents cannot be exported Right, only "repr(C)" types can show up in "extern" APIs. So no data-bearing enums, no Vec<T>, etc. > Will the gains in safety be contained entirely inside the modules that are written in Rust? I think for some things the answer is yes, and for other things the answer is no. If the issue is that callers might retain some pointer or descriptor longer than they should, leading to a use-after-free or something like that, then there's probably no way to fix that with an API-compatible Rust reimplementation. What safe Rust would prefer to do is either 1) force explicit lifetime constraints on the caller or 2) replace the pointer/reference with some sort of smart pointer, which can either keep its referent alive or at least safely detect the fact that the referent is dead. But of course a C-compatible API has no way to represent (1), and (2) would presumably be an incompatible API change, so the Rust reimplementation can't really solve this issue. (Though if both Rust and C APIs get exposed for the new code, then new Rust callers could benefit from (1).) On the other hand, if the issue is that the caller might pass in some invalid indexes or other metadata, leading to an out-of-bounds array access within the module, Rust can help quite a bit. If the array in question is actually owned by the module (and not just a raw pointer to unknown memory) then bounds checking is required one way or another (unless it's either optimized away or explicitly skipped with unsafe code), and a Rust reimplementation will probably not suffer from out-of-bounds issues. Raw pointers into the caller's memory are harder to check, but even there if they can be converted to a safe slice immediately inside the API boundary, some subset of out-of-bounds accesses can still be caught. Looking at these two different kinds of bugs, I think it's interesting to think about what "inside the module" means here. In both cases, the UB we want to prevent (either use-after-free, or an out-of-bounds access) is "caused" by the caller's mistakes outside the module, but "occurs" on lines of code inside the module. In the first case, Rust can't protect itself against a bad (C) caller, but in the second case it might be able to.