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