From owner-freebsd-current Sat Dec 20 02:52:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA06747 for current-outgoing; Sat, 20 Dec 1997 02:52:15 -0800 (PST) (envelope-from owner-freebsd-current) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA06732 for ; Sat, 20 Dec 1997 02:52:09 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA12085 for freebsd-current@freebsd.org; Sat, 20 Dec 1997 11:52:07 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id LAA29380; Sat, 20 Dec 1997 11:23:35 +0100 (MET) Date: Sat, 20 Dec 1997 11:23:35 +0100 (MET) Message-Id: <199712201023.LAA29380@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <199712200839.TAA23072@godzilla.zeta.org.au> <199712200912.UAA00292@freebsd1.cimlogic.com.au> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: Bruce vandalism again X-Original-Newsgroups: local.freebsd.current To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John Birrell wrote: > If the use of the __P macro in new code is discouraged, then FreeBSD > is not trying to keep K&R compatibility (like NetBSD insists on). So > we are *encouraging* ANSI prototypes. Then (IMO) code that is being > edited (for other reasons) should have its function definitions > changed to ANSI style at the same time, regardless of how much code > is regarded as new according to this silly statement. I'm all in favor of new-style definitions, but wouldn't bless the above sentence completely. If someone's doing a major overhaul, then yes, by all means. If ``is being edited'' means just a single change (perhaps only fixing a typo), moving the entire file to new-style function calls would just and only obfuscate the actual change that has been performed by the commit next time you run `cvs diff' on it again. The `style compatibility' issue has one point: you can look at the actual functional changes by comparing against the 4.4BSD vendor branch. If someone's going to break this by basically rewriting an entire driver/subsystem/whatever, then this becomes a non-issue anyway, and other cosmetic changes could be done by the same time (but preferrably in a second commit, so the functional and the cosmetic changes can be looked at separately). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)