Programming

17506 readers

32 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

snowe

Ategon

[email protected]

Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk (thenewstack.io)

submitted 3 weeks ago by arendjr to c/programming

32 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 10 points 3 weeks ago* (last edited 3 weeks ago) (14 children)

Seems excessive to convert everything to rust when you can use std::shared_ptr and std::weak_ptr to eliminate the memory safety issue?

[–] arendjr 31 points 3 weeks ago* (last edited 3 weeks ago) (8 children)

Using smart pointers doesn’t eliminate the memory safety issue, it merely addresses one aspect of it. Even with smart pointers, nothing is preventing you from passing references and using them after they’re freed.

[+] refalo -10 points 3 weeks ago (2 children)

To be fair, it's entirely possible to make the same and very similar mistakes in Rust, too.

[–] GetOffMyLan 7 points 3 weeks ago* (last edited 3 weeks ago)

I'm fairly sure use after free isn't possible unless you explicitly use unsafe code right?

It's compiler enforced is the point.

[–] robinm 1 points 2 weeks ago (1 children)

Is it possible to do in Rust?

Yes

Is possible to do in Rust, by mistake, and not easily caught by a review?

Definitively not.

[–] refalo 0 points 2 weeks ago (1 children)

I think you could argue the same point with C++

[–] robinm 1 points 2 weeks ago (1 children)

void foo() {
    std::vector v = {0, 1, 2, 4};
    const auto& ref = v[1];
    add_missing_values(v);
    std::cout << ref << "\n";
}

void add_missing_values(std::vector<int>& v) {
    // ...
    v.push_back(3);
}

Neither foo(), nor add_missing_values() looks suspicious. Nonetheless, if v.push_back(3) requires v to grow, then ref becomes an invalid reference and std::cout << ref becomes UB (use after free). In Rust this would not compiles.

It is order of magnitudes easier to have lifetime errors in C++ than in Rust (use after free, double free, data races, use before initialisation, …)

[–] refalo 1 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

This would be caught by ASan and other tools though, which should be part of any review.

[–] robinm 1 points 2 weeks ago

That's why I did not said it was impossible, just order of magnitude harder to catch in C++ compared to Rust.

To have asan finding the bug, you need to have a valid unit test, that has a similar enough workload. Otherwise you may not see the bug with asan if the vector doesn't grow (and thus ref would still be valid, not triggering UB), leading to a production-only bug.

Asan is a wonderfull tool, but you can't deny it's much harder to use and much less reliable than just running your compiler.

[–] robinm 0 points 1 week ago

I think you have a hard time understanding the différence between "not possible" and "much harder".

In Rust, the code does not compile.

In C++ the code compile, but

if you have a test case
this test case triggers the bug (it is not guarateed to properly reproduce you production environment since it depends on the parameters of the allocator of your vector)
you use ubsan

... then the bug will be caught.

Yes it is possible, noone says the opposite. But you can't deny it's harder. And because its harder, more bugs get past review, most notably security bugs as demonstrated again and again in many studies. The

load more comments (5 replies)

load more comments (10 replies)