[Mesa-dev] [PATCH 02/24] glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

[Eric Anholt]

Ian Romanick <idr at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130918/4935dea7/attachment.pgp>