Ian Romanick <i...@freedesktop.org> writes: > On 09/15/2013 02:10 AM, Francisco Jerez wrote: >> The _mesa_glsl_parse_state object relies on the memory allocator >> zeroing out its contents before it's initialized, which seems rather >> risky. One of the following commits will homogenize implementations >> of the new operator in a way that would break this assumption leaving >> some of the member variables of this object uninitialized. > > This was an intentional design decision that we made, after a fair > amount of consideration, in the early days of the compiler. A number of > factors came together: > > * Use of ralloc et al. meant that we could never have stack-allocated > objects. > > * Use of rzalloc meant that objects would always be pre-allocated to zero. > > * Uninitialized class member bugs are hard to track down. > > * It's easy to forget to add 'this->foo = 0;' when you add a field foo > to a class. > > * A dozen lines of 'this->foo = 0;' is hard to properly review when a > new class is added. Are there actually 13 fields that need to be > initialized? > > * Writing a dozen lines of 'this->foo = 0;' is annoying. :) > > In the end, we decided to just rely on the allocator always providing > cleared memory. > > I'm not very excited about adding a bunch of redundant code to the these > constructors... especially since that code probably won't get maintained > (e.g., when the next member gets added to those classes). > > I'd like to hear Ken and Eric weigh in.
Agreed completely.
pgpLmiSZnGJJt.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
