[Mesa-dev] [PATCH] st/mesa: init hash keys with memset(), not designated initializers

[Brian Paul]

On 03/11/2019 04:47 PM, Eric Anholt wrote:
> Brian Paul <brianp at vmware.com> writes:
> 
>> Since the compiler may not zero-out padding in the object.
>> Add a couple comments about this to prevent misunderstandings in
>> the future.
>>
>> Fixes: 67d96816ff5 ("st/mesa: move, clean-up shader variant key decls/inits")
>> ---
>>   src/mesa/state_tracker/st_atom_shader.c |  9 +++++++--
>>   src/mesa/state_tracker/st_program.c     | 13 ++++++++++---
>>   2 files changed, 17 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_atom_shader.c b/src/mesa/state_tracker/st_atom_shader.c
>> index ac7a1a5..a4475e2 100644
>> --- a/src/mesa/state_tracker/st_atom_shader.c
>> +++ b/src/mesa/state_tracker/st_atom_shader.c
>> @@ -112,7 +112,10 @@ st_update_fp( struct st_context *st )
>>          !stfp->variants->key.bitmap) {
>>         shader = stfp->variants->driver_shader;
>>      } else {
>> -      struct st_fp_variant_key key = {0};
>> +      struct st_fp_variant_key key;
>> +
>> +      /* use memset, not an initializer to be sure all memory is zeroed */
>> +      memset(&key, 0, sizeof(key));
> 
> Wait, what?  We rely on this form of initialization all over, what's
> changed?

The question is do all compilers, when presented with

struct st_fp_variant_key key = {0};

initialize the entire object to zero, or just the individual fields 
(skipping padding).

This matters for hash keys but shouldn't matter otherwise.

-Brian