Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

On Thu, Jan 28, 1999 at 08:01:33AM +0100, Luigi Rizzo wrote: > not speaking about vinum, but to me, the indentation of 8 char and > line length of 80 chars are almost mutually exclusive. I've managed to do this for years without much problem. When it is un-avoidable, you can always use a macro. -

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

Matthew Dillon wrote: >:Judicious use of inline functions (and macros) should help move >:code to the left - and may even make it more understandable. > >More then judicious use -- inlines are an incredible advantage. Most >people don't realize that GCC will optimize constant arguments th

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

On Friday, 29 January 1999 at 7:54:18 +1100, Peter Jeremy wrote: > Luigi Rizzo >> not speaking about vinum, but to me, the indentation of 8 char and >> line length of 80 chars are almost mutually exclusive. >> >> See e.g. tcp_input.c ip_input.c and many network device drivers as >> an example --

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

:> :> More then judicious use -- inlines are an incredible advantage. Most :> people don't realize that GCC will optimize constant arguments through :> an inline call. Try this: :> :> static __inline Yah, and if it's static it will not even output code for fubar. I've neve

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

Matthew Dillon wrote: > :Luigi Rizzo > :>not speaking about vinum, but to me, the indentation of 8 char and > :... > : > :According to most of the coding standards I've read, readability > :(and hence maintainability) come before efficiency. That said, I > :agree that efficiency _is_ an issue wit

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

:Luigi Rizzo :>not speaking about vinum, but to me, the indentation of 8 char and :... : :According to most of the coding standards I've read, readability :(and hence maintainability) come before efficiency. That said, I :agree that efficiency _is_ an issue within the kernel's critical :paths (th

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

Luigi Rizzo >not speaking about vinum, but to me, the indentation of 8 char and >line length of 80 chars are almost mutually exclusive. > >See e.g. tcp_input.c ip_input.c and many network device drivers as >an example -- basically all places where, for efficiency reasons, >the code tries to expand

Re: Nesting levels (was: indent(1) and style(9) (was: btokup() macro in sys/malloc.h))

On Thu, 28 Jan 1999, Greg Lehey wrote: > On Thursday, 28 January 1999 at 20:39:03 +1100, Bruce Evans wrote: > >> See e.g. tcp_input.c ip_input.c and many network device drivers as > >> an example -- basically all places where, for efficiency reasons, > >> the code tries to expand in-line various b

Re: btokup() macro in sys/malloc.h

< said: > Peter Jeremy wrote: >> >> I'll support that. The example given in style(9): >> >> a = b->c[0] + ~d == (e || f) || g && h ? i : j >> 1; >> >> should rate as an entry in the Obfuscated C competition rather than >> an example of maintainable code. > As a matter of fact, what's the rea

Re: btokup() macro in sys/malloc.h

John Polstra wrote: > On 28-Jan-99 John Birrell wrote: > > John Polstra wrote: > >> > >> Hear ye, hear ye! Be it here noted and archived for all eternity that > >> on January 27, 1999 Pacific Time, John Polstra was, for one fleeting > >> moment, purer than Bruce! :-) > > > >OK, so now w

Re: btokup() macro in sys/malloc.h

* From: John Polstra * On 28-Jan-99 Bruce Evans wrote: Hey John, are you sure your mailer is Y2K compliant? Satoshi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message

Re: btokup() macro in sys/malloc.h

Bruce Evans wrote: > > >It would be nice if style(9) documented the options to give indent(1) > >to match the `approved' layout convections. (This would reduce the > >effort involved in importing large chunks of code). > > This is impossible, since indent(1) is buggy and out of date with both >

Re: btokup() macro in sys/malloc.h

Peter Jeremy wrote: > > I'll support that. The example given in style(9): > > a = b->c[0] + ~d == (e || f) || g && h ? i : j >> 1; > > should rate as an entry in the Obfuscated C competition rather than > an example of maintainable code. As a matter of fact, what's the reasoning behind

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

> > >an example -- basically all places where, for efficiency reasons, > > >the code tries to expand in-line various block, the depth of > > >indentation pushes everything to the right end leaving only 20-30 > > >useful chars per line. > > > > See the Linux style guide (linux/Documentation/CodingS

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

> See the Linux style guide (linux/Documentation/CodingStyle) for Looks like an oxymoron to me. > Bruce -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of th

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

> They have an indentation of 4 > instead of 8, [.] 8 spaces is almost always *way* too much if a maximum of 80 columns is expected. IMHO, the requirement should be to either use TABs and only TABs or else two or more spaces. Either way, perhaps it's time someone fixed indent(1) so that it

Re: btokup() macro in sys/malloc.h

> A warning is just that. It's not an error, so don't treat it like one. I use different productions to enable different warnings on code with different histories. For one thing, new revs of the compiler will otherwise cause trouble when the warning behavior changes. I also use -Werror. Elimin

Re: btokup() macro in sys/malloc.h

>In cases, -Wall is bogus anyway. Here's one: >foo.c:89: warning: char format, void arg (arg 2) >void *region; >printf("mem open failed: %s\n", region); Yes, it should say "warning: char * format, void * arg (arg 2)". >According to standards, a void pointer may be freely u

Nesting levels (was: indent(1) and style(9) (was: btokup() macro in sys/malloc.h))

On Thursday, 28 January 1999 at 20:39:03 +1100, Bruce Evans wrote: >> not speaking about vinum, but to me, the indentation of 8 char and >> line length of 80 chars are almost mutually exclusive. >> >> See e.g. tcp_input.c ip_input.c and many network device drivers as >> an example -- basically all

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

> >an example -- basically all places where, for efficiency reasons, > >the code tries to expand in-line various block, the depth of > >indentation pushes everything to the right end leaving only 20-30 > >useful chars per line. > > See the Linux style guide (linux/Documentation/CodingStyle) for >

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

>not speaking about vinum, but to me, the indentation of 8 char and >line length of 80 chars are almost mutually exclusive. > >See e.g. tcp_input.c ip_input.c and many network device drivers as >an example -- basically all places where, for efficiency reasons, >the code tries to expand in-line vari

Re: btokup() macro in sys/malloc.h

On Thu, 28 Jan 1999, Poul-Henning Kamp wrote: > In message <199901280222.vaa14...@khavrinen.lcs.mit.edu>, Garrett Wollman > writes: > >< > said: > > > >> Please do go ahead and update it.. the experts agree! > > > >I haven't seen any experts involved in this discussion yet. It's > >probably af

Re: btokup() macro in sys/malloc.h

:In cases, -Wall is bogus anyway. Here's one: :foo.c:89: warning: char format, void arg (arg 2) :void *region; :printf("mem open failed: %s\n", region); : :According to standards, a void pointer may be freely used instead of any :other type of pointer, both as an lvalue and

Re: btokup() macro in sys/malloc.h

>>> Please do go ahead and update it.. the experts agree! >> >>I haven't seen any experts involved in this discussion yet. It's >>probably after bedtime down there in oz. > >It's been discussed before and agreed upon. There was only agreement long ago when the BSD4.4 /usr/src/admin/style was conv

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

> I see no evidence of this. vinum sources don't seem to have a single > line in KNF, except accidentally. They have an indentation of 4 > instead of 8, lots of per-statement comments, lots of lines longer > than 80 characters, lots of block comments without `/*' and `*/' on > a line by themself,

Re: btokup() macro in sys/malloc.h

Matt, Please leave your keyboard now. Get some sleep, some rest and a couple of days off. You need it, we need it. Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long t

Re: btokup() macro in sys/malloc.h

:Matt, : :By now we do know a GREAT deal about you from the way you behave. : :Trying to judge your age from that data, 16 years can certainly not :be ruled out conclusively. : :I will make no secret of the fact that I was not at all happy with :you becoming a committer, and your behaviour the las

Re: btokup() macro in sys/malloc.h

On Wed, 27 Jan 1999, Matthew Dillon wrote: > > :> then we need to update sytle(9) to reflect that. > :> > :> In fact, style(9) should say: > :> > :> If at all possible, your code should compile without warnings > :> when the gcc -Wall flag is given. > : > :I disagree. As has been shown man

Re: btokup() macro in sys/malloc.h

On Thu, 28 Jan 1999, John Birrell wrote: > Nate Williams wrote: > > > Anyway, if we're going to -Wall'ify the kernel (as we should) > > > then we need to update sytle(9) to reflect that. > > > > > > In fact, style(9) should say: > > > > > > If at all possible, your code should compile without

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

On Thu, Jan 28, 1999 at 06:05:37PM +1030, a little birdie told me that Greg Lehey remarked > On Thursday, 28 January 1999 at 14:16:25 +1100, Bruce Evans wrote: > >> It would be nice if style(9) documented the options to give indent(1) > >> to match the `approved' layout convections. (This would re

Re: btokup() macro in sys/malloc.h

Matt, By now we do know a GREAT deal about you from the way you behave. Trying to judge your age from that data, 16 years can certainly not be ruled out conclusively. I will make no secret of the fact that I was not at all happy with you becoming a committer, and your behaviour the last couple

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

On Thursday, 28 January 1999 at 19:19:12 +1100, Bruce Evans wrote: It would be nice if style(9) documented the options to give indent(1) to match the `approved' layout convections. (This would reduce the effort involved in importing large chunks of code). >>> >>> This is impossible,

Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

>>> It would be nice if style(9) documented the options to give indent(1) >>> to match the `approved' layout convections. (This would reduce the >>> effort involved in importing large chunks of code). >> >> This is impossible, since indent(1) is buggy and out of date with both >> KNF and C. > >Wel

Re: btokup() macro in sys/malloc.h

In message <199901280222.vaa14...@khavrinen.lcs.mit.edu>, Garrett Wollman writes: >< >said: > >> Please do go ahead and update it.. the experts agree! > >I haven't seen any experts involved in this discussion yet. It's >probably after bedtime down there in oz. It's been discussed before and agr

indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

On Thursday, 28 January 1999 at 14:16:25 +1100, Bruce Evans wrote: >> It would be nice if style(9) documented the options to give indent(1) >> to match the `approved' layout convections. (This would reduce the >> effort involved in importing large chunks of code). > > This is impossible, since ind

Re: btokup() macro in sys/malloc.h

I could drive there from here :-) On Wed, 27 Jan 1999, John Polstra wrote: > > On 28-Jan-99 John Birrell wrote: > > John Polstra wrote: > >> > >> Hear ye, hear ye! Be it here noted and archived for all eternity that > >> on January 27, 1999 Pacific Time, John Polstra was, for one fleeting > >

Re: btokup() macro in sys/malloc.h

> > In my experience, the resulting > > code tends to be more portable across architectures with different > > pointer/long sizes and endian-ness. > > This is where I disagree. Too often people cast away the bugs and end > up with overflow and sign problems. Since we haven't tried this yet, and

Re: btokup() macro in sys/malloc.h

Nate Williams writes: > > In fact, style(9) should say: > > > > If at all possible, your code should compile without warnings > > when the gcc -Wall flag is given. > > I disagree. As has been shown many times in the past (and I suspect the > down-under constituent will show that at least a c

Re: btokup() macro in sys/malloc.h

> :And introduced at least one. If you were a programmer under my charge, > :I'd tell you to use the warnings to fix only those bugs you are sure of > :and leave the others alone. > > Nate, if you were a programmer under my charge you'd be heading out > the door with your final paycheck.

Re: btokup() macro in sys/malloc.h

: :And introduced at least one. If you were a programmer under my charge, :I'd tell you to use the warnings to fix only those bugs you are sure of :and leave the others alone. Nate, if you were a programmer under my charge you'd be heading out the door with your final paycheck. Your at

Re: btokup() macro in sys/malloc.h

> :> then we need to update sytle(9) to reflect that. > :> > :> In fact, style(9) should say: > :> > :> If at all possible, your code should compile without warnings > :> when the gcc -Wall flag is given. > : > :I disagree. As has been shown many times in the past (and I suspect the > :down-

Re: btokup() macro in sys/malloc.h

> > > Fixing warnings with bad casts is a problem, sure, but asking people > > > to write code without casts (if possible) that will compile cleanly with > > > -Wall is a reasonable thing to ask IMO. > > > > Agreed. But most of the new code written does indeed compile with > > -Wall. It's the co

Re: btokup() macro in sys/malloc.h

Nate Williams wrote: > > Fixing warnings with bad casts is a problem, sure, but asking people > > to write code without casts (if possible) that will compile cleanly with > > -Wall is a reasonable thing to ask IMO. > > Agreed. But most of the new code written does indeed compile with > -Wall. It

Re: btokup() macro in sys/malloc.h

+[ John Birrell ]- | John Polstra wrote: | > Bah! You might be able to hit Bruce over there in oz. But to hit me, | > you'd need an ICBM. Give me purity or give me death! Bwahahahahah! | | Nah, I even tried poisoning Sydney's water with something

Re: btokup() macro in sys/malloc.h

> > 'warnings' fixes will be wrong and hide bogus code), making -Wall a goal > > causes people to cover up bad code with bad casts and such. > > > > '-Wall' is *NOT* a good design goal. > > Fixing warnings with bad casts is a problem, sure, but asking people > to write code without casts (if poss

Re: btokup() macro in sys/malloc.h

John Polstra wrote: > Bah! You might be able to hit Bruce over there in oz. But to hit me, > you'd need an ICBM. Give me purity or give me death! Bwahahahahah! Nah, I even tried poisoning Sydney's water with something I can't spell, but even that didn't kill off Bruce. The government told peop

Re: btokup() macro in sys/malloc.h

:I think you must mean the "Sydney-down-under constituent". There *is* :a difference. 8-) : :> 'warnings' fixes will be wrong and hide bogus code), making -Wall a goal :> causes people to cover up bad code with bad casts and such. :> :> '-Wall' is *NOT* a good design goal. : :Fixing warnings with

Re: btokup() macro in sys/malloc.h

On 28-Jan-99 John Birrell wrote: > John Polstra wrote: >> >> Hear ye, hear ye! Be it here noted and archived for all eternity that >> on January 27, 1999 Pacific Time, John Polstra was, for one fleeting >> moment, purer than Bruce! :-) > > OK, so now we have to shoot you too. Oh well, so be it.

Re: btokup() macro in sys/malloc.h

:> then we need to update sytle(9) to reflect that. :> :> In fact, style(9) should say: :> :> If at all possible, your code should compile without warnings :> when the gcc -Wall flag is given. : :I disagree. As has been shown many times in the past (and I suspect the :down-under constituent

Re: btokup() macro in sys/malloc.h

John Polstra wrote: > On 28-Jan-99 Bruce Evans wrote: > > Nah, style(9), not to mention the example of btokup() in Lite1 and Lite2, > > requires paretheses here (in btokup(), and probably in the bad example in > > style(9), because the expression would be really confusing without them :-). > > Hea

Re: btokup() macro in sys/malloc.h

Nate Williams wrote: > > Anyway, if we're going to -Wall'ify the kernel (as we should) > > then we need to update sytle(9) to reflect that. > > > > In fact, style(9) should say: > > > > If at all possible, your code should compile without warnings > > when the gcc -Wall flag is given. > > I

Re: btokup() macro in sys/malloc.h

On 28-Jan-99 Bruce Evans wrote: >>The added parentheses don't make any difference, semantically. This >>change probably wouldn't meet the criteria spelled out in style(9): >> >> Unary operators don't require spaces, binary operators do. Don't use >> parentheses unless they're required for

Re: btokup() macro in sys/malloc.h

> Anyway, if we're going to -Wall'ify the kernel (as we should) > then we need to update sytle(9) to reflect that. > > In fact, style(9) should say: > > If at all possible, your code should compile without warnings > when the gcc -Wall flag is given. I disagree. As has been shown many times

Re: btokup() macro in sys/malloc.h

>> Is this parenthesization correct ? >> >> OLD >> >> #define btokup(addr)(&kmemusage[(caddr_t)(addr) - kmembase >> >> PAGE_SHIFT]) >> >> NEW >> >> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> >> PAGE_SHIFT]) Yes. It is the same as before the "cleanup"

Re: btokup() macro in sys/malloc.h

Bruce Evans writes: > >In fact, style(9) should say: > > > > If at all possible, your code should compile without warnings > > when the gcc -Wall flag is given. > > Avoiding warnings is more an engineering than a stylistic matter. > You turn on warnings to help avoid bugs that the compiler can f

Re: btokup() macro in sys/malloc.h

>It would be nice if style(9) documented the options to give indent(1) >to match the `approved' layout convections. (This would reduce the >effort involved in importing large chunks of code). This is impossible, since indent(1) is buggy and out of date with both KNF and C. Bruce To Unsubscribe:

Re: btokup() macro in sys/malloc.h

Matthew Dillon wrote: >:style(9) should emphasize legibility and maintainability, rather than >:minimizing the number of extraneous (from the compiler's perspective) >:parenthesis. >As far as parenthesis go, it's irrelevant because -Wall pretty much >covers the most common mistakes. I was

Re: btokup() macro in sys/malloc.h

>Anyway, if we're going to -Wall'ify the kernel (as we should) >then we need to update sytle(9) to reflect that. > >In fact, style(9) should say: > > If at all possible, your code should compile without warnings > when the gcc -Wall flag is given. Avoiding warnings is more an engineering than a

Re: btokup() macro in sys/malloc.h

On Thu, 28 Jan 1999, Peter Jeremy wrote: > Matthew Dillon wrote: > >:> NEW > >:> > >:> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> > >PAGE_SHIFT]) > >: > >:The added parentheses don't make any difference, semantically. This > >:change probably wouldn't meet the crit

Re: btokup() macro in sys/malloc.h

:Matthew Dillon wrote: :>:> NEW :>:> :>:> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> PAGE_SHIFT]) :>: :>:The added parentheses don't make any difference, semantically. This :>:change probably wouldn't meet the criteria spelled out in style(9): :> :>Then style(9)

Re: btokup() macro in sys/malloc.h

Garrett Wollman writes: > > Please do go ahead and update it.. the experts agree! > > I haven't seen any experts involved in this discussion yet. It's > probably after bedtime down there in oz. It was discussed before a couple of weeks ago, and I didn't hear anybody on the other side. I could be

Re: btokup() macro in sys/malloc.h

Matthew Dillon wrote: >:> NEW >:> >:> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> >PAGE_SHIFT]) >: >:The added parentheses don't make any difference, semantically. This >:change probably wouldn't meet the criteria spelled out in style(9): > >Then style(9) needs t

Re: btokup() macro in sys/malloc.h

< said: > Please do go ahead and update it.. the experts agree! I haven't seen any experts involved in this discussion yet. It's probably after bedtime down there in oz. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem

Re: btokup() macro in sys/malloc.h

Matthew Dillon writes: > :> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> > PAGE_SHIFT]) > : > :The added parentheses don't make any difference, semantically. This > :change probably wouldn't meet the criteria spelled out in style(9): > > Then style(9) needs to be updat

Re: btokup() macro in sys/malloc.h

that line was confusing enough for me... I think style (9) needs to be relaxed a bit on that I think the bit about parns just intriduces bug "opportunities" and certainly the bit about braces DEFINATLY introduces bugs. Braces and parens allow humans to understand the and read the code with less c

Re: btokup() macro in sys/malloc.h

:> NEW :> :> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> PAGE_SHIFT]) : :The added parentheses don't make any difference, semantically. This :change probably wouldn't meet the criteria spelled out in style(9): Then style(9) needs to be updated, because we have t

Re: btokup() macro in sys/malloc.h

In article <199901272128.naa56...@apollo.backplane.com>, Matthew Dillon wrote: > Is this parenthesization correct ? > > OLD > > #define btokup(addr)(&kmemusage[(caddr_t)(addr) - kmembase >> PAGE_SHIFT]) > > NEW > > #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembas

btokup() macro in sys/malloc.h

Is this parenthesization correct ? OLD #define btokup(addr)(&kmemusage[(caddr_t)(addr) - kmembase >> PAGE_SHIFT]) NEW #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> PAGE_SHIFT]) -Matt To Unsubscribe: send mail to maj