From owner-freebsd-current  Tue Mar 12 11:52:00 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id LAA10119
          for current-outgoing; Tue, 12 Mar 1996 11:52:00 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA10112
          for <current@freebsd.org>; Tue, 12 Mar 1996 11:51:57 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA02539; Wed, 13 Mar 1996 06:46:25 +1100
Date: Wed, 13 Mar 1996 06:46:25 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199603121946.GAA02539@godzilla.zeta.org.au>
To: bde@zeta.org.au, wollman@lcs.mit.edu
Subject: Re: cvs commit:  src/sys/sys conf.h
Cc: current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>> (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)

64-bit int, 128-bit long, 96-bit pointer (? ...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.

It doesn't help at runtime, and may waste space and time.

Bruce