You should have test cases to verify the zeroing behavior in the object code. Even if the standard says a compiler must do something does not mean that it does.
The difficult thing is that any way to verify the zeroing behavior would change the compiler's decision about whether it could elide the call to memset. So it's possible (well, almost guaranteed) that the test would succeed even though the memory wouldn't actually be zeroed in production.
Remember that we're trying to mitigate exploits. The test code could just be an exploit. Either that or just dump and analyze the memory.
If you set up your tests up correctly they should test the exact binary or shared library that is deployed to production and not some test-specific build.
I was thinking about that. I think the way to do the test would be to put in a known key value, then call the platform-specific equivalent of "abort and write a core file". The test would then grovel through the core looking for the known key sequence.