Holes in structs and opEquals

[yigal chripun]

Walter Bright Wrote:

> 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.

The compiler knows at compile-time what variables are initialized with "=void". The compiler than can add a compilation error when such a struct variable is used in an equals expression. 
this doesn't cover use of malloc() which must be the user's responsebility. 

e.g.
 S s1=void,s2=void;
 s1.s=0; s1.d=0;
 s2.s=0; s2.d=0;
 assert(s1 == s2); // <- this line should not compile