On 03/11/2019 04:47 PM, Eric Anholt wrote:
Brian Paul <bri...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
