From owner-freebsd-chat Thu Feb 6 09:00:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA15241 for chat-outgoing; Thu, 6 Feb 1997 09:00:35 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA15234 for ; Thu, 6 Feb 1997 09:00:31 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id RAA16312; Thu, 6 Feb 1997 17:58:46 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id SAA29789; Thu, 6 Feb 1997 18:00:51 +0100 (MET) Message-Id: <3.0.32.19970206180051.00abec10@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Feb 1997 18:00:52 +0100 To: Garrett Wollman From: Eivind Eklund Subject: Re: cvs commit: CVSROOT avail Cc: chat@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:30 PM 2/3/97 -0500, Garrett Wollman wrote: >< said: > >> Is it only for hystorical reasons that most things still are K&R? > >Well, it depends on which part of `K&R' you are referring to. It is >indeed only for historical reasons that many user programs have no >parameter type-safety at all. However, most newer code will have >prototypes even if the function definitions are still in the >traditional format (which some people prefer, although I'm not one, >and which the style guide still strongly encourages). "Strongly encourages" == "We could not agree. For new subsystems, choose what you feel is more important"? :) Anyway; I would not recommend using ANSI prototypes and K&R style definitions - this can create some weird parameter conversions which are unlikely to give much problems on a machine with pure 32-bit parameter passing, but can potentially give weird problems on later ports. Besides, C9X at least seemed to be going to abolish K&R style function prototypes (which was what I meant). I'll get back to you on whether they still plan to do that. >My approach would be to follow traditional style in terms of >indentation, brace placement, comment formatting, spacing, and so on, >but to always use new-style function declarations and definitions in >new code. Agreement from me. Are there (still, 2 years after the copyright on style(9) ) enough people out there that disagree strongly enough that it would be wrong to recommend this? >Some other rules which are not all entirely written down, >and some of which disagree with style(9): > >5) Never use NULL. Write it `0', and provide casts as appropriate. This is makes it more difficult to see, and provide less typechecking. Casts must be provided as appropriate, of course. >7) Don't use continuation lines in strings. Are you really talking of continuation lines, or do you mean string concatenation or in-string newlines? (Not using continuation lines seems so obvious when string concatenation is available - if it is tolerated.) >11) Don't use in lint(1) ``control comments''. Nobody uses lint. I've just turned into "nobody". :) >> If there isn't any guidelines, I believe some guidelines for which style we >> want (not require) for submissions to FreeBSD might be a good thing - I can >> throw together a draft and throw it at -hackers. > >Actually, throwing it at -hackers is probably counterproductive. >Throw it at cvs-committers; these are the people for whom it really >makes a difference. I'll see if I can find the time to do this one day not too far into the future - I can probably adopt part of the "good coding practice" parts from a document I've written for my company. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/