The problem with C++ is it still allows a lot of unsafe ways of working with memory that previous projects used and people still use now.

Why do you think this is a problem? We have a tool that gives everyone the freedom to manage resources the way it suits their own needs. It even went as far as explicitly supporting garbage collectors right up to C++23. Some frameworks adopted and enforced their own memory management systems, such as Qt.

Tell me, exactly why do you think this is a problem?

The problem is that you need some support from the language to make it easy to deal with.

Nonsense.

if (result.isSuccess()) {
    do_something(result.value);
}
else {
   handle_error(result error);
}

If you had a grasp on the subject you'd understand that it takes more than mindlessly chanting "tools" to actually get tangible improvements, and even I'm that scenario often they come with critical tradeoff.

It takes more than peer pressure to make a case for a tool.

The maintainer is a human that needs to eat every day, and not just whenever their services are needed.

That's perfectly fine.

But the maintainer is indeed explicitly making his work available to the public for free and without any expectation of retribution of any kind, isn't it?

And this isn't exactly something new or recent or novel, right? That's been going on for many years.

What changed? Did anything changed at all, even?

It’s not that they made a big report. It’s that they, a multi-billion dollar company,

Why do you think this is even relevant? Again, does your attitude towards a run of the mill ticket change if you change who filed it? Why are you outraged because some random grunt from company A or B filed an issue instead of random joe X? Would you be commenting here if the very same person who filed the issue had done so with a personal account without identifying or disclosing their employer?

It’s that they do nothing for the project but expect the world from it.

I'm sorry, where does ffmpeg demand contributions or retributions from anyone who downloads or distributes their project? Aren't they explicitly distributing their work without asking anyone to do or give anything in return? I mean, isn't that the whole point of FLOSS?

More surprisingly, we see guides on how to contribute to FLOSS projects which state in no uncertain terms that filing bug reports and even run exploratory tests to give feedback to maintainers counts as contributing to the project, but somehow you've flipped over even the core principles to make it sound like a cash grab.

This is a flippant statement, honestly, as it disregards the premise of the discussion. It’s memory safety.

You're completely ignoring even the argument you're supposedly commenting,let alone the point it makes. You're parroting cliches while purposely turning a blind eye to the point made in the blog that yes C can be memory safe. Likewise, Rust also has CVEs due to memory safety bugs. So, beyond these cliches, what exactly are you trying to argue?

I think this can be explained by underlining the differences between could, would, and should.

The blog states the fact that at least some C compilers already offer the necessary and sufficient tools that characterize "memory-safe" languages, and proceeds to illustrate examples. This isn't new. However, just like "memory-safe" languages enforce narrow coding styles through a happy path that is expected to prevent the introduction of some classes of vulnerabilities, leveraging these compiler features in C projects also requires the same type of approach.

This isn't new or unheard of. Some C++ frameworks are also known for supporting their own memory management and object ownership strategies, but you need to voluntarily adhere to them.

It sounds like you’ve never had to do real work in a language kind C++ where the compiler is always trying to play gotcha with undefined behavior.

I have over a decade of professional experience working with C++, and it's likely you already used software I worked on.

Throughout those years, the total number of times where undefined behavior posed a problem in any of the projects I worked on was zero.

Please enlighten me about the insurmountable challenges posed by undefined behavior.

How do you succinctly call a language that has all behavior defined or equivalently no undefined behavior (aside from designated regions)?

I don't understand this fixation with undefined behavior. Its origins are in the design decision of leaving the door open for implementations to employ whatever optimization techniques they see fit without the specification get in the way. This is hardly a problem.

In practical terms, developers are mindful to not rely on those traits because as far as specifications go they have unpredictable implications, but even so they are never a problem. I mean, even in C and C++ it's trivial to tweak the compiler to flag undefined behavior as warnings/errors.

Sometimes it sounds like detractors just parrot undefined behavior as some kind of gotcha in ways I'm not even sure they fully understand.

What problem do you think that undefined behavior poses?

User first, non-profit software companies.

How do you expect to keep a non-profit software company afloat?

Should have still used them. It was harder to read this way.

The blog author is literally using de-facto standard for placeholder names.

• https://en.wikipedia.org/wiki/Foobar
• https://www.techopedia.com/definition/27996/frobnicate

The var names used by the author are perfectly fine. They don't cause any issue, nor do they make things hard to read.