Date: Tue, 28 Apr 2009 21:47:54 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Christoph Mallon <christoph.mallon@gmx.de> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: C99: Suggestions for style(9) Message-ID: <20090428114754.GB89235@server.vk2pj.dyndns.org> In-Reply-To: <49F4070C.2000108@gmx.de> References: <49F4070C.2000108@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Apr-26 09:02:36 +0200, Christoph Mallon <christoph.mallon@gmx.de> w= rote: >as some of you may have noticed, several years ago a new millenium=20 >started and a decade ago there was a new C standard. Your implication that FreeBSD is therefore a decade behind the times is unfair. Whilst the C99 standard was published a decade ago, compilers implementing that standard are still not ubiquitous. > HEAD recently=20 >switched to C99 as default (actually gnu99, but that's rather close). Note that gcc 4.2 (the FreeBSD base compiler) states that it is not C99 compliant. >Maybe using all of these changes is a bit too big change at once, but=20 >I'd like some of them applied to style(9). So, please consider the=20 >proposed changes individually and not a as a all-or-nothing package. One area you do not address is code consistency. Currently, the FreeBSD kernel (and, to a lesser extent, userland) are mostly style(9) compliant - ie the entire codebase is mostly written in the same style. Whilst you may not like it (and I don't know that anyone completely agrees with everything in style(9)), it does mean that the code is consistent. Changing style(9) in a way that is not consistent with current code means that either existing code must be brought into line with the new standard - which incurs a one-off cost - or the code base becomes split into "old" and "new" style - incurring an ongoing maintenance cost as maintainers switch between styles. Both approaches incur a risk of introducing new bugs. Note that I'm not saying that style(9) can never be changed, I'm just saying that any change _will_ incur a cost and the cost as well as the potential benefits need to be considered. [Reduce declaration scope as far as possible, initialise variables where they are declared, sort by name] Whilst my personal preference is for the style suggested by Christoph (and I generally agree with the points he makes), this is also the change that incurs the biggest stylistic change. This is not a change that can be practically retrofitted to existing code and therefore its implementation would result in a mixture of code styles - increasing the risk of bugs due to confusion as to which style was being used. I am not yet sure whether the benefits outweigh the costs, [Don't parenthesize return values] >Removed, because it does not improve maintainability in any way. This change could be made and tested mechanically. But there is no justification for making it - stating that the existing rule is no better than the proposed rule is no reason to change. [No K&R declarations] >Removed, because there is no need to use them anymore. Whilst this is a change that could be performed mechanically, there are some gotchas relating to type promotion (as you point out). The kernel already contains a mixture of ANSI & K&R declarations and style(9) recommends using ANSI. IMHO, there is no need to make this change until all K&R code is removed from FreeBSD. [ Don't insert an empty line if the function has no local variables.] This change could be made and tested mechanically. IMHO, this change has neglible risk and could be safely implemented. >> +.Sh LOCAL VARIABLES >Last, but definitely not least, I added this paragraph about the use of=20 >local variables. This is to clarify, how today's compilers handle=20 >unaliased local variables. Every version of gcc that FreeBSD has ever used would do this for primitive types when optimisation was enabled. This approach can become expensive in stack (and this is an issue for kernel code) when using non-primitive types or when optimisation is not enabled (though I'm not sure if this is supported). Assuming that gcc (and icc and clang) behaves as stated in all supported optimisation modes, this change would appear to be quite safe to make. --=20 Peter Jeremy --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkn27OoACgkQ/opHv/APuIesggCZAYozgHNOftliuEVWqEHVRqZR fREAnjb2liAo0fpJ+9oyqhnxIksXWm4A =HkGc -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090428114754.GB89235>