From owner-svn-src-head@freebsd.org Mon Feb 22 10:41:26 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAE5FAB048D; Mon, 22 Feb 2016 10:41:26 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F1DC134B; Mon, 22 Feb 2016 10:41:25 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u1MAfNc7096702 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2016 10:41:24 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: svn commit: r295768 - head/usr.sbin/iostat From: David Chisnall In-Reply-To: Date: Mon, 22 Feb 2016 10:41:17 +0000 Cc: Dimitry Andric , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , Sergey Kandaurov , "src-committers@freebsd.org" , Alan Somers Content-Transfer-Encoding: quoted-printable Message-Id: <08BD1DAA-4B07-48C3-BEF2-4D4FBDB5071F@FreeBSD.org> References: <201602182008.u1IK81vg092127@repo.freebsd.org> <83BB8467-4C40-4CF1-B394-1376C9D97FCF@FreeBSD.org> <156A6796-D62B-4977-893B-E4E727578412@FreeBSD.org> To: koobs@FreeBSD.org X-Mailer: Apple Mail (2.2104) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 10:41:26 -0000 On 22 Feb 2016, at 10:15, Kubilay Kocak 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