On Fri, 19 Feb 2016, Benjamin Kaduk wrote:
On Fri, Feb 19, 2016 at 5:06 PM, Gleb Smirnoff <gleb...@freebsd.org> wrote:
On Fri, Feb 19, 2016 at 08:49:43AM -0700, Alan Somers wrote:
A> On Fri, Feb 19, 2016 at 5:24 AM, Sergey Kandaurov <pluk...@gmail.com>
wrote:
A> Yeah, it was being implicitly zeroized before. But Clang complained
A> about the structures being only partially initialized. Since the
A> whole point of my commit was to increase the WARNS level, I explicitly
A> zeroed the zero fields to silence Clang.
Isn't zero filling part of the standard? I don't see why lack of
explicit zeroing is a warning? Looks a false warning to me.
It is not quite as simple as this would make it sound. The elements or
members of an aggregate (e.g.) structure type are initialized as if it were
an object of static storage duration (i.e., to zero) if the initializer
list does not contain enough initializers for all members of the aggregate
type, per item 21 of section 6.7.8 of n1256.pdf. However, such
initialization does not necessarily need to zero any padding bytes that are
present, which may take unspecified values.
Perhaps, but then there is even less reason to expect that initializing
all the struct members initialzes the padding between them.
Personally, I think this
particular clang warning can be too aggressive, especially for complex
structs, but on the other hand given the indeterminateness of padding,
bzero/memset are often a better choice anyway.
It is just a bug in clang.
Using auto structs with initialzers, auto structs initialized by memset/
bzero followed by initializing a few fields, are almost equally good
pessimizations. Some compilers generate similar code for them (like the
code shown by pluknet -- the initializer is optimized to an inlined
memset followed by initializing 1 field. But doing this this on every
function call is a good pessimization if the struct never changes or
rarely changes or only changes slightly. Some compilers generate the
worse code of keeping a static copy and generating an inline memcpy to
the auto variable on every function call.
6.7.8p9 says that unnamed members have indeterminate values even after
initialization, except where explicitly stated otherwise.
I couldn't find anywhere "explicitly stating otherwise" that padding
is initialized. It takes an explicit statements in p21 to get the
unnamed members in an initializer initialized, but padding isn't even.
p21 says that any unnamed struct member is initialized as if it had
static storage duration with no initializer, but I couldn't find
anything requiring initialization for padding in that case. Apparently,
only quality of implementation prevents it being initialized with
passwords from the previous program :-(.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
