svn commit: r295768 - head/usr.sbin/iostat

[Benjamin Kaduk]

On Fri, Feb 19, 2016 at 6:50 PM, Conrad Meyer <cem at freebsd.org> wrote:

> On Fri, Feb 19, 2016 at 3:14 PM, Benjamin Kaduk <bjkfbsd at gmail.com> wrote:
> > On Fri, Feb 19, 2016 at 5:06 PM, Gleb Smirnoff <glebius at freebsd.org>
> wrote:
> >> 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.  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.
>
>
> By definition, padding byte contents are unused.  There is no reason
> their values matter one way or another, so why do we care about the
> distinction between bzero and member zero initialization?
>

Well, you can access them by treating the object as an array of char, and
then memory sanitizer will complain about the uninitialized access, as in
https://github.com/openssl/openssl/commit/f0496ad71fbacccf5a95f40d31d251bc8cf9dcfb

-Ben

P.S. Not really apropos of anything, but clang also has -Weverything which
is just what it sounds like (as opposed to -Wall), which is a great way to
expose several other warnings that Bruce will call bugs :)