[jstimpfle]

I've looked at a couple of these complaints by clang-tidy, and as it unfortunately often is, all of them were false positives and overzealous nitpicks. All the complaints about memcpy and memset for example, clang-tidy could easily be improved to see that these are just fine and being dogmatic about using the "new and right way" to do things is not helpful.

In practice I've found -Wall with GCC to offer a good warning level and clang-tidy to not offer a lot of constructive feedback (besides it being very slow). For more ambitious projects, it's possible to fine-tune GCC warnings.

You can also, you know, just _use_ a program and see if there are any anomalies when running it. With some discipline to code structure, many problems get hit on the first run, and extensive testing can come a lot closer to static verification than you would think. For non-real-time constrained stuff there is also valgrind and other run-time instrumentation.

[pjmlp]

Instead of ranting, you should have realized that is the default output without configuration file, which isn't that easily to provide in compiler explorer, without going through the trouble of a project template.

Naturally on a real project there would be an heavily customised static analysis tool, that would only allow a build to succeed with the feedback from the SecDevOps team, alongside feedback loop from pentesters.

We have seen how far just _use_ the program has been a thing tracking down C security issues for the last 37 years, starting with Morris Worm.

And to quote Dennis Ritchie,

> To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

-- https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist...

[jstimpfle]

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).

[pjmlp]

Were they false positives though?

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.

[jstimpfle]

> Were they false positives though?

I've looked at them -- not all of them but all that I've looked at were the same kind recommending memcpy_s instead of memcpy, and were ridiculously easily to classify as false positives. So yes.

> How come "which isn't that easily to provide in compiler explorer, " suddenly becomes me telling that was impossible?

You claimed it wasn't easy but it is easy. VERY easy. It's one flag to disprove your point. Be honest.

> 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.

Many still enjoy it, are productive, and are creating infrastructure for billions of people to use. Let's keep things in relation.

[paulf38]

I always assume that anyone that says that something is a false positive without providing any rigorous proof has confirmation bias and are sadly deluding themselves about their ability and the correctness of their code.

[jstimpfle]

I said "probably" because the other messages from clang-tidy were so low quality obvious false positives too, a waste of time. I've already given the remaining warning a look and the code seemed fine to me. I didn't follow the whole massive linter output. Did you?