Date: Fri, 01 May 2009 13:30:15 +0200 From: Christoph Mallon <christoph.mallon@gmx.de> To: Julian Elischer <julian@elischer.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) Message-ID: <49FADD47.7060507@gmx.de> In-Reply-To: <49FAB322.9030103@elischer.org> References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <49FAB322.9030103@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer schrieb: > As an old-fart I have found many cases where what I thought was > a silly style rule, turned out to save my work in some way. > > Christoph Mallon wrote: > > >>> >>> >>> struct foo *fp; >>> struct bar *bp; >>> >>> fp = get_foo(); >>> if (!fp) return; >>> bp = fp->bp; >>> >>> this can't easily be translated to the more natural: >>> >>> struct foo *fp = get_foo(); >>> struct bar *bp = fp->bp; > > Well more natural for you, but not necessarily for everyone, > and NOT the same as what is there now, as you noticed. You partially misquoted this (only my name is seen above). I did not write this, Warner did. But I agree with Warner, that it is more natural. Also Warner had the wrong impression that declarations and statements cannot be mixed. But this is not true and so you can put the if inbetween, which is seen below. >>> >>> since really you'd want to write: >>> >>> struct foo *fp = get_foo(); >>> if (!fp) return; >>> struct bar *bp = fp->bp; >>> >>> which isn't legal in 'C'. However, we have enough where this isn't >> >> You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 (E) >> §6.8.2:1. In short: you can mix statements and declarations. > > now, but not all C compilers are C99 and a lot of FreeBSD code > is taken and run in other situations. There is FreeBSD code > in all sorts of environments, not all of which have new compilers. There are already several C99 features in use (like designated initialisers). So this is obviously not a problem. > Besides which I'd vote against that just on principle that it breaks > current style too much, and it makes it hard to find where things are > declared. "Changes cannot be done because something would be different" is - of course - the killer pseudo-argument against any kind of change ever. ): >>> >>> : [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. > > This is not new. It's already policy to remove them whenever you are > working in the area. it improves code error checking.. So clearly style(9) should reflect this by removing the paragraph. >>> >>> : [ 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. >>> >>> I'm fine with this change. >> >> Would you commit these three proposals? >> >>> : >> +.Sh LOCAL VARIABLES >>> : : >Last, but definitely not least, I added this paragraph about the >>> use of : >local variables. This is to clarify, how today's compilers >>> handle : >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. >>> >>> Agreed, in general. We don't want to optimize our code style based on >>> what one compiler does, perhaps on x86. > > it does however make it harder to find stuff in gdb Can you elaborate on this? Because I cannot follow what you mean by this. "p i" will still print the value of "i". > As a general rule, one of the things that is good about BSD code is that > it all looks about the same. This makes it easier to read, once you have > got used to it. Again this is the same "any change cannot happen, because it changes something which not already is this way" circular argument. ): If you don't dare to take the first step at some point, nothing can ever change and no improvement can take place ever. It's sad that changes (like designated initialisers) have to creep in via the backdoor and then at some point you can say "See? The world did not end.", because for any proposed change always somebody objects with "this is bad, because it is different than before". ): > changing it for no reason except "I felt like it" will and I think > should, meet stiff opposition. I want to make absolutely clear, that I in no way said or implied "I felt like it". I explained the reason for any of the changes I propsed and none of the reasons is even close to "I felt like it". Christoph
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49FADD47.7060507>