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

David Chisnall theraven at FreeBSD.org
Mon Feb 22 10:41:26 UTC 2016


On 22 Feb 2016, at 10:15, Kubilay Kocak <koobs at FreeBSD.org> wrote:
> 
> 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’s 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’re 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’t initialise a field, then the compiler can typically tell that you’ve read from a field but not written to it.  It’s 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’t 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’s 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



More information about the svn-src-all mailing list