Holes in structs and opEquals

[Walter Bright]

Fawzi Mohamed wrote:
> one could argue that the unsafe operation is memset.

That's right.


> The compiler always initializes a struct, so that what you describe 
> should never happen in a safe program.

Right.


> Still as you say the following example that might indeed considered a bug:
> 
> S s1=void,s2=void;
> s1.s=0; s1.d=0;
> s2.s=0; s2.d=0;
> assert(s1 == s2);
> 
> here the assert might fail depending on the previous content of the memory.
> I am not sure of what is the best solution, I am not sure that defining 
> a special comparison operation by default for each struct is the correct 
> solution (it can be quite some bloat), please note that a user defined 
> comparison function will not have these problems.

No, it's not a bug in the language, it's a bug in the user code. Using 
=void is an advanced feature, and it requires the user to know what he's 
doing with it. That's why it isn't allowed in safe mode.


> Still I agree that traking down a bug due to this might be very ugly...

The idea with =void initializations is that they are findable using 
grep, and so can be singled out for special attention when there is a 
problem.