> As soon as a pointer to said memory is passed to an extern function in another translation unit, the compiler can't prove anything about how it's used, which is the case in pretty much all of the examples mentioned in this thread.
You would have to call such a function between the memset and the first time you write to a member. Otherwise the compiler is allowed to say "I put the padding back, and you can't prove otherwise".
> Just because reading the padding of some struct is undefined behaviour doesn't mean accessing those bits by some other means is also undefined.
It's not always undefined, but it says very clearly that the value of padding becomes unspecified.
> they almost always pass a reference to a routine in another translation unit
> you're massively overstating the relevance of compilers eliminating dead stores done via memset
Unless inlining happened, or link-time optimization, or, or...
If the compiler zeroes the memory most of the time, that makes it even scarier. Because all your tests come back clean and safe, then four years later a macro changes and suddenly you're leaking data all over the place.
I don't think I'm overstating the relevance at all. Any security feature that could disappear because of a reasonable, trying-to-help optimization is one that should have a bright red warning label. And this is such a feature. It doesn't require a "sufficiently smart" compiler, and it doesn't require a malicious compiler. This is the kind of thing that can break by accident and ruin everyone's month.