Anton Pevtsov wrote:
Martin Sebor wrote:
That means that the compiler doesn't always zero-initialize objects of
POD-type.
[...]
Regarding to _RW::__nullref:
The problem seems to be in the _RW::__nullref dereferencing - its
fields contains garbage.
That should never happen. The object is a POD and should be all zeros.
In our case the _RWSTD_NO_POD_ZERO_INIT is defined. So, is it possible
that _RW::__nullref' s fields may contain non-zero values after the
initialization?
I don't think it's possible. The macro has to do with the
initializer of the declaration (i.e., the right-hand side
of the assignment operator). __nullref doesn't have an
initializer so it must be zeroed out at load time (as
opposed to runtime).
If yes, maybe, it will be useful to zero this memory manually to avoid
this problem in any case?
That would require running code (like memset) which would
change the initialization from static (load time) to dynamic
(runtime). Since there might be other dynamically initialized
objects that use __nullref and since their initializers might
run before the one for __nullref this wouldn't help.
Martin
