|
|
|
|
|
by jstimpfle
229 days ago
|
|
Instead of ranting and showing a huge warnings output to make a point fitting your agenda, you could have just disabled the false positives yourself (like I did, by the way) and you would have seen that that vastly reduces the warnings. Oh, and to disprove your other claim, here is a link to the godbolt with added clang-tidy flag: https://godbolt.org/z/G31Ws8aa1 . This has the clang-tidy invocation changed to disable a single warning category : --checks='-clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling' . Running with that, there remains only a single warning. Which is probably a false positive as well. If there are real concerns about this code, show them. I'm not saying there can't be any. But it doesn't help your credibility if you continue arguing your claims with evidence that is easily disproved. I have nothing against tooling that actually improve the situation. Btw. that `lint` from almost 50 years ago that you're referencing is probably easily covered by `-Wall` or `-Wextra` alone. I was also mentioning valgrind. Bottom line, you're vastly exaggerating the gravity of the memory bugs inflicted upon us by memory-unsafe languages, compared to other bugs which exist too. (Maybe I like the term memory-dangerous better). |
|
How come "which isn't that easily to provide in compiler explorer, " suddenly becomes me telling that was impossible?
If you enjoy typing a endless list of clang-tidy flags on a tiny text box, well fun is on the user.
The first concern is that some parts of the industry keep reaching to C when there are better alternatives, even the language authors have moved on to creating better languages.