From owner-freebsd-current Tue Oct 21 23:51:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA10844 for current-outgoing; Tue, 21 Oct 1997 23:51:01 -0700 (PDT) (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 SMTP id XAA10835 for ; Tue, 21 Oct 1997 23:50:57 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA26917 for current@FreeBSD.ORG; Wed, 22 Oct 1997 08:50:56 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA20854; Wed, 22 Oct 1997 08:32:38 +0200 (MET DST) Message-ID: <19971022083238.XB35355@uriah.heep.sax.de> Date: Wed, 22 Oct 1997 08:32:38 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! References: <199710220240.MAA23169@godzilla.zeta.org.au> <19971022072818.27417@keltia.freenix.fr> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 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 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19971022072818.27417@keltia.freenix.fr>; from Ollivier Robert on Oct 22, 1997 07:28:18 +0200 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Ollivier Robert wrote: > According to Bruce Evans: > > style.9 says not to obfuscate code by initializes variables in > > declarations. > I tried to be consistent with the code around in null_vnops.c... Do you > think we should change both miscfs/nullfs and miscfs/umapfs to conform to > style(9) ? The code has been like this since 4.4BSD-lite... We've already changed style(9) to make it less strict than it used to be. Function calls are forbidden (since they might cause ill side-effects when someone tries to make the code thread-safe for SMP). One must be cautious with macros like VTONULL() since they could actually impose a function call (even if they don't do now, someone might get the idea to change a low-level interface later, and hide it inside such a macro). Of course, for C++ code, the restriction needs to be rethought. There's often a big difference between an initializer, and a declaration followed by an assignment, in C++ (the declaration might be not useful without the initializer, depending on your constructors). -- 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. ;-)