Revert one change from b3d113e #8603
Conversation
mspncp
left a comment
There was a problem hiding this comment.
LGTM, provided the commit message is corrected and Travis succeeds.
Valgrind complains due to the uninitialized memory
between the struct members, assigning { 0 } was zeroing the memory
assigning { NULL, 0 } is like assigning member-wise, leaving
some bytes uninitialized.
06574ae to
700c5b8
Compare
|
Right, I dropped the "a" now. |
kroeckx
left a comment
There was a problem hiding this comment.
This does not actually result in any change, the padding bytes can still be uninitialized.
|
This should be a memset if you want to ensure the entire structure is cleared ... and if you are referencing the padding items in any context that means you are using the structure as a "whole" and that means it should have been initialised as a whole (via memset). |
|
Yes, if my message wasn't clear, you need a memset
|
|
Fixed in #8606 |
|
Note, but I saw similar constructs elsewhere. |
|
For instance here: openssl/crypto/rand/rand_unix.c Lines 614 to 618 in cd353c7 |
|
There are multiple instances of this :( I checked the C89 standard and it is ambiguous in one place in indicates that this would initialise the first field to zero, leaving the rest undefined. In a later example the implication is that all fields would be initialised but no mention about padding. Just to cause more confusion, for an array, any excess elements would be initialised to zero. |
|
I've addressed all the rand ones in #8610. I believe they are all harmless since they are providing personalisation material. I'll check other instances in the tree separately. |
Valgrind complains due to the uninitialized memory
between the struct members, assigning { 0 } was zeroing the memory
assigning { NULL, 0 } is like assigning member-wise, leaving
some bytes uninitialized.
Checklist