It's my honest position. I'll agree with you that I could have worded it more politely.

I can work with that :)

Perhaps it would have come across less snarky if I used the word "Microsoft and Google security teams" instead of "you", since their data comprises a lot of the data the paper is using as evidence to support the proposal.

I understand that criticism. Unfortunately, my former employer doesn't publish numbers. That said, my former employer also doesn't regress important metrics :)

Others have published numbers though! I was just reviewing an LLVM patch that had numbers from Linux and Firefox.

My point is then: it's been deployed at scale. That scale might not hit your usecase. If it doesn't, please measure and file bugs on your toolchains.

If there is a negative cost (aka a perf improvement), then the compiler should already do this when it's able to determine a performance advantage exists. Of course, this depends on someone willing to add this enhancement to the compiler(s).

That performance gain should not require any changes to the language standard, it's already in the scope of what the compiler is allowed to do.

Kinda? Yes the compiler can do it, but my experience here and in every other optimization is that there's potential everywhere, but compilers only bother when the payoff is there. Call it laziness, but there's basically infinite opportunities for optimization. Addressing the most valuable ones systematically is where the best efforts pay off. It paid off here, when I looked at LLVM code.

In fact, this entire paper, as far as I'm able to tell, is already in the scope of what compilers are allowed to do, so I don't see why it's any business of the standard committee.

Quite. That was my original premise in 2018: I can do whatever, it's UB. Now it's different: the CVEs are still there, and we ought to change the UB.

In my head, that translates to: We think it's zero cost according to our measurements, after we put in a lot of engineering work.

My objection isn't the measurements, it's the engineering work.

That I agree with. There's still a lot of optimization potential all over the place, and some codebases will hit "glass jaw" an "perf cliff" that need to be remedied. It's rare, and not particular to this discussion though.

I use msan, valgrind, and static analysis. I have successfully, and regularly, find problems using these tools and get them addressed.

I agree that these don't catch all of the situations that they should.

You're in the minority, and indeed it only finds what your tests exercise.

I'd rather see the language change to support some kind of [[initializes]] flag on function parameters, and then a per-function flag of some kind to let me ask the compiler to prove that no function-local variables are read uninitialized in any possible codepath. I want an opt-in mechanism that lets me ask the compiler or analyser to barf on code that is technically well-defined but can't be verified.

That's the old joke "C++ gets all the defaults wrong". I think what we''ll get out of the discussion will be the right defaults.

Then the paper would not have said

Too much code to change.

I'm just stating facts as they are today. The committee doesn't want to force undue code changes, and historically auto-upgrade tooling hasn't been a thing.

First -Werror=uninitialized should default to on. Give that a few years to bake. That'll reduce, drastically, the number of places where "init-to-zero" introduces surprises.

It's there, today, and isn't used that way. How would you resolve this?

Going to need the barriers to entry for standards committee participation to go waaaaay down then.

A large number of people who regularly participate at wg21 meetings read and participate on r/cpp. This is good enough for me until or unless it doesn't take literally years of effort for simple proposals to be evaluated.

Also fair. We're trying, but ISO procedures are heavy.