Chromium project finds that 70% of security defects are memory safety problems

Re:Chromium project finds that 70% of security defects are m... by fluffything on Monday May 25, 2020 @03:39AM (#23298920)

The claim is probably that idiomatic code in one case is faster than idiomatic code in the other, not that you can't write C++ code that isn't equally fast.

For example, if you use `std::vector` or `std::unique_ptr` you would be deallocating memory when those go out of scope. The JVM might actually never do that, e.g., if the program terminates before sufficient memory pressure arises.

Writing Rust code that leaks a `std::vector` is trivial, but doing the same in C++ actually requires some skill.

[ Parent | on HN ]

Re:Chromium project finds that 70% of security defects are m... by vardump on Monday May 25, 2020 @05:23AM (#23299448)

Writing C++ code that leaks a std::vector is absolutely trivial, happens all the time and requires no skill.

  auto* v = new std::vector<char>();

[ Parent | on HN ]

Re:Chromium project finds that 70% of security defects are m... by fluffything on Monday May 25, 2020 @06:16AM (#23299693)

I disagree in that it requires no skill: it requires the user to avoid doing the obvious thing:

    vector<int> foo {...};

and heap allocate a vector on the heap with `new` (without using a smart pointer), and then avoiding your linters warnings about this (e.g. clang-tidy).

If this is common in your place of work, I truly pity you.

Also, trading a call to `free` for a second call to malloc, and a second pointer indirection to the vector elements, isn't a very effective way of improving performance to beat the JVM. The whole idea behind leaking memory is doing less operations, not more :D

In Rust, leaking "the right way" is trivial (mem::forget is safe), but in C++, leaking the stack allocated vector probably requires putting it behind an union or aligned_storage or similar.

[ Parent | on HN ]