From owner-freebsd-current Tue Mar 12 08:26:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA26476 for current-outgoing; Tue, 12 Mar 1996 08:26:13 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA26467 for ; Tue, 12 Mar 1996 08:26:06 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA07546; Tue, 12 Mar 1996 11:25:58 -0500 Date: Tue, 12 Mar 1996 11:25:58 -0500 From: "Garrett A. Wollman" Message-Id: <9603121625.AA07546@halloran-eldar.lcs.mit.edu> To: Bruce Evans Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/sys conf.h In-Reply-To: <199603120520.QAA31894@godzilla.zeta.org.au> References: <199603120520.QAA31894@godzilla.zeta.org.au> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: >> (struct mbuf *)cmd, (struct mbuf *)data, (struct mbuf *)0)); > Actually, this is another point in favor of not making the ioctl cmd > field long. Longs are less likely to fit in pointers than ints. The > above would certainly fail for 16-bit pointers. So what? We are never going to have to deal with this situation. The only situations of relevance are: 32-bit int, 32-bit long, 32-bit pointer (all 32-bit systems) 32-bit int, 64-bit long, 64-bit pointer (Alpha) 64-bit int, 64-bit long, 64-bit pointer (Cray? ...will happen some day) It works fine in the first case, and it avoids a GCC warning in the second case. Sounds like the right thing to me. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant