Date: Mon, 22 Feb 2016 10:41:17 +0000 From: David Chisnall <theraven@FreeBSD.org> To: koobs@FreeBSD.org Cc: Dimitry Andric <dim@FreeBSD.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Sergey Kandaurov <pluknet@gmail.com>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Alan Somers <asomers@freebsd.org> Subject: Re: svn commit: r295768 - head/usr.sbin/iostat Message-ID: <08BD1DAA-4B07-48C3-BEF2-4D4FBDB5071F@FreeBSD.org> In-Reply-To: <a6572bea-434f-108b-03ff-e2b6541ad66b@FreeBSD.org> References: <201602182008.u1IK81vg092127@repo.freebsd.org> <CAE-mSO%2B7p=Equq81PPQjfZv1piPydBr4Mnk363CEs3w9EXRi9w@mail.gmail.com> <CAOtMX2hyZ=GFgp8F6t0dMDYF5FSPdoP9KdMU7V5rmscpaPUnsw@mail.gmail.com> <83BB8467-4C40-4CF1-B394-1376C9D97FCF@FreeBSD.org> <156A6796-D62B-4977-893B-E4E727578412@FreeBSD.org> <a6572bea-434f-108b-03ff-e2b6541ad66b@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 Feb 2016, at 10:15, Kubilay Kocak <koobs@FreeBSD.org> wrote: >=20 > For the lay persons among us (I'm genuinely interested), what are the > the downsides to requiring initialization of all fields? Explicit initialisation, or initialisation in general? Being able to initialise the entire structure with code that will always = initialise everything with zero makes the code less fragile because you = can add a field to the structure and not have to find all of the places = where it=E2=80=99s initialised. The clang warning makes it easy to find = the places you need to change, but now you have code churn for no good = reason. Implicit initialisation is often useful for generating more efficient = code. If you=E2=80=99re intialising with a bunch of common fields, the = compiler will end up creating a static variable and doing a memcpy = (which the back end may optimise), which is very cheap. A load of code = in libc ends up like this. > And in addition, the upsides, if any, of 'deferred' field = initialization? The same as the upsides for deferred variable initialization. Modern = compilers are good at tracking intraprocedural data flow. If you = don=E2=80=99t initialise a field, then the compiler can typically tell = that you=E2=80=99ve read from a field but not written to it. It=E2=80=99s= generally good defensive programming for zero to have a well-defined = meaning (C codifies this for pointers, Go codifies it for all structure = types), but if you haven=E2=80=99t done this then the zero may be a = valid but incorrect value and no amount of static analysis can tell you = that the programmer did something that is valid but wrong. Some = languages with richer type systems explicitly encode the invalidity of = the variable in its type and transform it to the valid version once it = is initialised (some also provide maybe types as a programmer-level = constructs. You can implement them fairly trivially in C++, see for = example LLVM=E2=80=99s ErrorOr<> template). Sane coding style for C (not style(9)) typically includes the principle = of minimum scope, where variables must be declared as close to possible = their initialisation. This helps minimise these problems, because you = either declare the variable where it is initialised, or (if = initialisation is conditional) right next to it where you can clearly = see that it has been initialised on all code paths. Unfortunately, as = you can see from the PVS results, style(9) could have been carefully = designed to maximise the introduction of accidental bugs. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?08BD1DAA-4B07-48C3-BEF2-4D4FBDB5071F>