1 comment:
Patchset:
oh. Actually in API functions it is fine for padding bytes to be returned random.
Yes, it's fine. Because a regular user does not care about padding bytes in structs. But the unit test does, because it uses `memcpy()` to compare the whole chunk of memory.
except if you are saying, a struct that has been memset(0) has its padding bytes overwritten randomly by *foo = (struct foo){} ... in my world so far that does not happen, but if zero padding does not stay zero, that would be a reason to memset(0) in the API implementation too, and that would change how I understand struct initialization.
This is exactly what I am saying and for me this was a new experience seeing that valgrind reports (I was not able to reproduce this with ASAN) uninitialized memory access, despite that part of memory has been explicitly initialized in the unit test with `memset()`. The C11 standard is clear on this though: "... the bytes of the object representation that correspond to any padding bytes take unspecified values".
I just find memset(0) looks ugly, and regression tests are allowed to look ugly, API implementations not so much.
Agreeing with Harald here. I see nothing wrong using it.
We should actually be careful with `{}`, as it's a non-standard GCC's extension.
https://stackoverflow.com/questions/17589533/is-an-empty-initializer-list-valid-c-code/54409687#54409687
To view, visit change 31505. To unsubscribe, or for help writing mail filters, visit settings.