Hello,
On Sat, Apr 06, 2002 at 06:51:14PM -0800, Jos Backus wrote:
One problem with ports is that configure will cause malloc.h to be used if
it exists in /usr/include (net/rsync being the latest example), causing an
annoying warning. So why not remove /usr/include/malloc.h, and patch those
One problem with ports is that configure will cause malloc.h to be used if
it exists in /usr/include (net/rsync being the latest example), causing an
annoying warning. So why not remove /usr/include/malloc.h, and patch those
ports/programs that still use it to use stdlib.h instead?
Thoughts
Hello Jörg et al,
# Just for grins, i dug out my old CP/M C compiler. (SuperSoft C, 1983
# vintage) That one's the only one so far i've seen where
#
# #if __STDC__
#
# wouldn't work as expected -- but
#
# #if (__STDC__ - 1) == 0
#
# wouldn't either. Apparently, this compiler substituted a
On Sat, 10 Nov 2001 14:52:22 +0100, Jens Schweikhardt [EMAIL PROTECTED]
said:
As I understand it, the only problem is if some implementation indicates
non-conformance with #define __STDC__ 0, which is unheard of to me, and,
if I were an implementor of such a system, I'd just leave it
On Thu, 8 Nov 2001, Garrett Wollman wrote:
On Thu, 8 Nov 2001 22:59:15 +0100, Joerg Wunsch [EMAIL PROTECTED] said:
Well, no. Solaris uses #if (__STDC__-1==0) only in connection with
other conditions in the same #if part. Otherwise, they use a simple
#ifdef __STDC__ as well.
FreeBSD
Matthew Dillon dil...@apollo.backplane.com 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
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.
In message 199901280222.vaa14...@khavrinen.lcs.mit.edu, Garrett Wollman
writes:
On Wed, 27 Jan 1999 18:00:54 -0800 (PST), Archie Cobbs arc...@whistle.com
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
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.
Well, you can do a
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, since indent(1)
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
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 reduce
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 warnings
when
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 many times in the
: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
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
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, ...
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 converted to a
: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
On Thu, 28 Jan 1999, Poul-Henning Kamp wrote:
In message 199901280222.vaa14...@khavrinen.lcs.mit.edu, Garrett Wollman
writes:
On Wed, 27 Jan 1999 18:00:54 -0800 (PST), Archie Cobbs
arc...@whistle.com said:
Please do go ahead and update it.. the experts agree!
I haven't seen any
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 various
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
strong
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 places
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 used
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.
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
See the Linux style guide (linux/Documentation/CodingStyle) for
Looks like an oxymoron to me.
Bruce
--
Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org
http://www.Awfulhak.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to majord...@freebsd.org
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
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 this
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
KNF and
* From: John Polstra j...@polstra.com
* 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
John Polstra j...@polstra.com 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 we
On Thu, 28 Jan 1999 19:56:37 +0900, Daniel C. Sobral d...@newsguy.com
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
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 block, the
Luigi Rizzo lu...@labinfo.iet.unipi.it
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
:Luigi Rizzo lu...@labinfo.iet.unipi.it
: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
Matthew Dillon wrote:
:Luigi Rizzo lu...@labinfo.iet.unipi.it
: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
:
: 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 never
On Friday, 29 January 1999 at 7:54:18 +1100, Peter Jeremy wrote:
Luigi Rizzo lu...@labinfo.iet.unipi.it
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
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
In article 199901272128.naa56...@apollo.backplane.com,
Matthew Dillon dil...@apollo.backplane.com wrote:
Is this parenthesization correct ?
OLD
#define btokup(addr)(kmemusage[(caddr_t)(addr) - kmembase PAGE_SHIFT])
NEW
#define btokup(addr)
: 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 to add
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
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 updated,
On Wed, 27 Jan 1999 18:00:54 -0800 (PST), Archie Cobbs arc...@whistle.com
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
Matthew Dillon dil...@apollo.backplane.com 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
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
:Matthew Dillon dil...@apollo.backplane.com 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):
:
:
On Thu, 28 Jan 1999, Peter Jeremy wrote:
Matthew Dillon dil...@apollo.backplane.com 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
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
Matthew Dillon dil...@apollo.backplane.com 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
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:
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 find
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 in rev.1.13.
The added
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 in
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
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 disagree. As
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 :-).
Hear ye,
: 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 will
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
Are
: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 bad
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
'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 possible) that
+[ 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
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's the
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 code we've
: 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
:
: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
: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.
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 couple of
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 since
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
moment, purer
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 indent(1)
73 matches
Mail list logo
