On 22 Feb 2016, at 10:15, Kubilay Kocak <ko...@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

_______________________________________________
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"

Reply via email to