headers
M. Warner Losh | 1 May 2009 02:37

Re: C99: Suggestions for style(9)

In message: <20090430233648.GA95360 <at> keira.kiwi-computer.com>
            "Rick C. Petty" <rick-freebsd2008 <at> kiwi-computer.com> writes:
: On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote:
: > 
: > This is the biggest one, and I think it may be too soon.  Also, we
: > need to be careful on the initialization side of things because we
: > currently have a lot of code that looks like:
: > 
: > 
: > 	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;
: > 
: > 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'.
: 
: I thought we were talking about C99, in which case this is perfectly legal.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Christoph Mallon | 1 May 2009 07:49
Picon
Picon

Re: C99: Suggestions for style(9)

M. Warner Losh schrieb:
> In message: <20090428114754.GB89235 <at> server.vk2pj.dyndns.org>
>             Peter Jeremy <peterjeremy <at> optushome.com.au> writes:
> : >Maybe using all of these changes is a bit too big change at once, but 
> : >I'd like some of them applied to style(9). So, please consider the 
> : >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.
> 
> This is my biggest worry about changing style(9) quickly.  We don't
> want needless churn in the tree for just style changes since it makes
> it harder to track bug fixes into the past.

I'm not saying that all the code has to be changed at once, but no new
(Continue reading)

Permalink | Reply | 9 comments |
headers
Christoph Mallon | 1 May 2009 07:54
Picon
Picon

Re: C99: Suggestions for style(9)

M. Warner Losh schrieb:
> In message: <20090430233648.GA95360 <at> keira.kiwi-computer.com>
>             "Rick C. Petty" <rick-freebsd2008 <at> kiwi-computer.com> writes:
> : On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote:
> : > 
> : > This is the biggest one, and I think it may be too soon.  Also, we
> : > need to be careful on the initialization side of things because we
> : > currently have a lot of code that looks like:
> : > 
> : > 
> : > 	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;
> : > 
> : > 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'.
> :
(Continue reading)

Permalink | Reply | 8 comments |
headers
Christoph Mallon | 1 May 2009 07:57
Picon
Picon

Re: C99: Suggestions for style(9)

Roman Divacky schrieb:
> I like the part about using as many variables as possible because
> of documentation and performance enhancements. I tend to like
> the other changes as well..

This is not about using as many variables as possible. The goal is to 
use as many variables as you have logically distinct entities in the 
function. I suppose, this is what you mean, but I want to clarify this 
point.

	Christoph
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 2 comments |
headers
Julian Elischer | 1 May 2009 10:30

Re: C99: Suggestions for style(9)

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.

>>
>> 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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Julian Elischer | 1 May 2009 10:33

Re: C99: Suggestions for style(9)

Christoph Mallon wrote:
> M. Warner Losh schrieb:
>> In message: <20090430233648.GA95360 <at> keira.kiwi-computer.com>
>>             "Rick C. Petty" <rick-freebsd2008 <at> kiwi-computer.com> writes:
>> : On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote:
>> : > : > This is the biggest one, and I think it may be too soon.  
>> Also, we
>> : > need to be careful on the initialization side of things because we
>> : > currently have a lot of code that looks like:
>> : > : > : >     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;
>> : > : > 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'.
>> : : I thought we were talking about C99, in which case this is 
>> perfectly legal.
>> : I certainly use it all the time in my C99 code.
>>
>> Hmmm, looks like that was added.  That's ugly as C++...
> 
> I do not think, this is ugly. On the contrary, it aids maintainability, 
> because it reduces the scope of variables. Also quite some variables are
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruce Cran | 1 May 2009 10:41
Picon
Gravatar

Re: C99: Suggestions for style(9)

On Fri, 01 May 2009 01:30:26 -0700
Julian Elischer <julian <at> elischer.org> wrote:

> Christoph Mallon wrote:
> >>
> >> 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.
> 

Doesn't FreeBSD already use C99 features such as stdint and named
initializers?  I don't think sys/cam/scsi/scsi_ses.c would
compile with a C89 compiler for example.

--

-- 
Bruce Cran
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christoph Mallon | 1 May 2009 13:30
Picon
Picon

Re: C99: Suggestions for style(9)

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christoph Mallon | 1 May 2009 13:37
Picon
Picon

Re: C99: Suggestions for style(9)

Marius Strobl schrieb:
> On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
>> return with parentheses:
>> Removed, because it does not improve maintainability in any way. There 
>> is no source for confusion here, so the rule even contradicts the rule, 
>> which states not to use redundant parentheses. Maybe, decades ago it was 
>> just a workaround for a broken compiler, which does not exist anymore.
> 
> FYI, the idea behind this rule is said to be to able to use
> a macro return(), f.e. for debugging you then can do:
> #define	return(x) do {							\
> 	printf("returning from %s with %d\n", __func__, (x));		\
> 	return (x);							\
> } while (0)
> 
> Given the this is a nifty feature and parentheses around the
> return value don't hurt maintainability in any way IMO this
> rule should stay.

This is mentioned nowhere in style(9) (in general it is lacking reasons 
why something is some way or the other).
Also I consider this as gross abuse: Macro names shall be in all 
uppercase, so it is clear that there is a macro at work. Therefore 
"return" is not a candidate. So this would violate yet another rule in 
style(9) (the original return already violates the no-redundant 
parentheses rule).
Also I would not mention __func__: there were objections against using 
it in the past (though I, logically, prefer its use).

	Christoph
(Continue reading)

Permalink | Reply | 6 comments |
headers
Marius Strobl | 1 May 2009 13:22
Picon

Re: C99: Suggestions for style(9)

On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
> 
> return with parentheses:
> Removed, because it does not improve maintainability in any way. There 
> is no source for confusion here, so the rule even contradicts the rule, 
> which states not to use redundant parentheses. Maybe, decades ago it was 
> just a workaround for a broken compiler, which does not exist anymore.

FYI, the idea behind this rule is said to be to able to use
a macro return(), f.e. for debugging you then can do:
#define	return(x) do {							\
	printf("returning from %s with %d\n", __func__, (x));		\
	return (x);							\
} while (0)

Given the this is a nifty feature and parentheses around the
return value don't hurt maintainability in any way IMO this
rule should stay.

Marius

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 8 comments |

Gmane