this post was submitted on 17 Jan 2024
1 points (50.8% liked)

Programming

17043 readers
311 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

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 !webdev@programming.dev



founded 1 year ago
MODERATORS
1
Rust vs C (programming.dev)
submitted 8 months ago* (last edited 8 months ago) by modev@programming.dev to c/programming@programming.dev
 

Without any ::prelude and some void* arguments. Maybe you have thoughts about it.

The URL is just a sample of "why" but not "because".

I have my own preference but will keep it inside my mind to not burn a tornado that will erase me from the matrix of the world.

P.S.: I think C is faster, more powerful, and more elegant. I like it more than Rust.

you are viewing a single comment's thread
view the rest of the comments
[–] lysdexic@programming.dev -1 points 8 months ago* (last edited 8 months ago) (1 children)

You are making an extreme assumption, and it also sounds like you’ve misread what I wrote. The “attempts” I’m talking about are studies (formal and informal) to measure the root causes of bugs, not the C or C++ projects themselves.

I think you're talking past the point I've made.

The point I've made is that the bulk of these attempts don't even consider onboarding basic static analysis tools for projects. Do you agree?

If you read the post of other studies you've quoted, you'd be aware that some of them quite literally report results of onboarding a single static analysis tool to C or C++ projects. The very first study in your list is quite literally the results of onboarding projects to Hardware-assisted AddressSanitizer, after acknowledging that they haven't onboarded AddressSanitizer due to performance reasons. The second study in your list reports results of enabling LLVM’s bound sanitizer.

Yet, your personal claim over "the lack of memory safety" in languages like C or C++ is unexplainably based on failing to follow very basic and simple steps like onboarding any static analysis tool, which is trivial to do. Yet, your assertion doesn't cover that simple step. Why is that?

Again, I think this comparison is disingenuous. You take zero effort to address whole family of errors and then proceed to claim that whole family of errors are not addressed, even though nowadays there's a myriad of ways to tackle those. That doesn't sound like a honest comparison to me.

[–] BatmanAoD@programming.dev 2 points 8 months ago

You're misunderstanding the posts you're explaining. Sanitizers, including ASan, HWASan, and bound sanitizer, are not "static analysis tools". They are runtime tools, which is why they have a performance impact. They're not intended to be deployed as part of a final executable.

I don't know how you can read this sentence and interpret it to mean that they "haven't onboarded AddressSanitizer":

In previous years our memory bug detection efforts were focused on Address Sanitizer (ASan).