3 ms·

>"1 memory error every 1000 lines" One memory error per 1000 LOC? I think they probably either use old style C++ or something else weird and ignore all static

by FpUser 4y ago

>"1 memory error every 1000 lines" One memory error per 1000 LOC? I think they probably either use old style C++ or something else weird and ignore all static and runtime memory safety tooling to get to this error rate in their releases. >"And they didn't have one yet in 1.5 million lines of Rust" I assume that those 1.5 "million lines" do not contain any unsafe features Rust allows for. Am I correct here?

Yoric 4y ago
> I assume that those 1.5 "million lines" do not contain any unsafe features Rust allows for. Am I correct here? I would assume that there are a few `unsafe` lines of code in these 1.5 MLoC. Which still makes it easier to trust than 1.5MLoC of C++ in which (by Rust definitions of `unsafe`) every line makes use of `unsafe` features. (insert usual caveats about tradeoffs, etc.)
zapnuk 4y ago
> One memory error per 1000 LOC? From his link: "Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production."
- FpUser 4y ago
  As already said this error rate for released code seems way too high. No idea what they're doing internally but they definitely doing something wrong. Probably sticking to old style with lots of explicit memory management.
  - pjmlp 4y ago
    Yeah, but that is the thing, most C++ shops write code exactly like that, regardless of what a few iluminated souls write about modern C++ and static analysis best pratices. Not even Bjarne's continuous preaching seems to affect current practices, as most folks don't do social activities regarding their day job programming languages.
    - 72deluxe 4y ago
      But that's not the language's fault. As a C++ developer I worked with developers who were scared to use the STL and were using MFC containers in 2017. Still using Visual Studio 2008 because it would take a mammoth task to move the 6.5 million LOC to a modern IDE. They eventually did it when I left but even the senior developers were oblivious to C++11 features like move semantics, lambdas etc. Hopeless. It's not the fault of the language if developers are lazy or use the tool badly.
      - nindalf 4y ago
        Yeah it's not quite language's fault if the language provides a better way to do the same . But equally, the language does provide a bad way to do things. A developer in a hurry, or a developer trying to follow the existing convention in the code base, or a developer making a reasonable assumption that's later invalidated - there's no sense in blaming these folks either. We can admonish them all we like, but the bugs keep appearing. I think it's better to be hard on tools, not people. We can make give the people better tools. Telling them the tool is fine and the problem is with them isn't productive and doesn't lead to better software.
      - pjmlp 4y ago
        It is not the car's fault if people manage to crash and die by not using ESP, ABS and seatbelts.
Gwypaas 4y ago
> I assume that those 1.5 "million lines" do not contain any unsafe features Rust allows for. Am I correct here? Because as Rust grows it is easier to model more behavior and less unsafe is needed. They mention this in the article. > There are exactly two uses of unsafe in the UWB code: one to materialize a reference to a Rust object stored inside a Java object, and another for the teardown of the same. Unsafe was actively helpful in this situation because the extra attention on this code allowed us to discover a possible race condition and guard against it. > In general, use of unsafe in Android’s Rust appears to be working as intended. It’s used rarely, and when it is used, it’s encapsulating behavior that’s easier to reason about and review for safety. https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language...

by FpUser 4y ago

Yoric 4y ago

> I assume that those 1.5 "million lines" do not contain any unsafe features Rust allows for. Am I correct here? I would assume that there are a few `unsafe` lines of code in these 1.5 MLoC. Which still makes it easier to trust than 1.5MLoC of C++ in which (by Rust definitions of `unsafe`) every line makes use of `unsafe` features. (insert usual caveats about tradeoffs, etc.)

zapnuk 4y ago

> One memory error per 1000 LOC? From his link: "Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production."

FpUser 4y ago
As already said this error rate for released code seems way too high. No idea what they're doing internally but they definitely doing something wrong. Probably sticking to old style with lots of explicit memory management.
- pjmlp 4y ago
  Yeah, but that is the thing, most C++ shops write code exactly like that, regardless of what a few iluminated souls write about modern C++ and static analysis best pratices. Not even Bjarne's continuous preaching seems to affect current practices, as most folks don't do social activities regarding their day job programming languages.
  - 72deluxe 4y ago
    But that's not the language's fault. As a C++ developer I worked with developers who were scared to use the STL and were using MFC containers in 2017. Still using Visual Studio 2008 because it would take a mammoth task to move the 6.5 million LOC to a modern IDE. They eventually did it when I left but even the senior developers were oblivious to C++11 features like move semantics, lambdas etc. Hopeless. It's not the fault of the language if developers are lazy or use the tool badly.
    - nindalf 4y ago
      Yeah it's not quite language's fault if the language provides a better way to do the same . But equally, the language does provide a bad way to do things. A developer in a hurry, or a developer trying to follow the existing convention in the code base, or a developer making a reasonable assumption that's later invalidated - there's no sense in blaming these folks either. We can admonish them all we like, but the bugs keep appearing. I think it's better to be hard on tools, not people. We can make give the people better tools. Telling them the tool is fine and the problem is with them isn't productive and doesn't lead to better software.
    - pjmlp 4y ago
      It is not the car's fault if people manage to crash and die by not using ESP, ABS and seatbelts.

Gwypaas 4y ago

> I assume that those 1.5 "million lines" do not contain any unsafe features Rust allows for. Am I correct here? Because as Rust grows it is easier to model more behavior and less unsafe is needed. They mention this in the article. > There are exactly two uses of unsafe in the UWB code: one to materialize a reference to a Rust object stored inside a Java object, and another for the teardown of the same. Unsafe was actively helpful in this situation because the extra attention on this code allowed us to discover a possible race condition and guard against it. > In general, use of unsafe in Android’s Rust appears to be working as intended. It’s used rarely, and when it is used, it’s encapsulating behavior that’s easier to reason about and review for safety. https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language...