From owner-freebsd-bugs Mon May 29 11: 0:18 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id A39CB37BD54 for ; Mon, 29 May 2000 11:00:14 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id LAA61146; Mon, 29 May 2000 11:00:13 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 29 May 2000 11:00:13 -0700 (PDT) Message-Id: <200005291800.LAA61146@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Anatoly Vorobey Subject: Re: kern/18874: 32bit NFS servers export wrong negative values to 64bit clients Reply-To: Anatoly Vorobey Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/18874; it has been noted by GNATS. From: Anatoly Vorobey To: Alexander Langer Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/18874: 32bit NFS servers export wrong negative values to 64bit clients Date: Mon, 29 May 2000 13:59:24 -0400 You, Alexander Langer, were spotted writing this on Mon, May 29, 2000 at 07:48:21PM +0200: > Thus spake Anatoly Vorobey (mellon@pobox.com): > > > it to long. Then it'll hold the real negative value which must be correctly > > converted into long. I know that you can point out that Alpha's long was > > bigger than i386's long -- but there's not much you can do about *that*, > > since you have to start from struct statfs on Alpha and finish with struct > > statfs on i386, and f_bavail is long on both. You'll just have to hope that > > the underlying filesystem restricts this value to 32 bits or something. > > What about taking quad_t and not u_quat_t? > > I think that would be _much_ more appreciated, isn't it? (for the > conversion) NFS seems to transfer everything unsigned, and I think it's a reasonable decision. It gets cast back to signed on the receiving end if needed. I think that casting to quad_t *before* casting to u_quad_t would solve the problem I've outlined as Scenario C in my previous mail. That change would have to be inserted in nfs_serv.c, in the server nfs_statfs() call. But I haven't even verified that the problem exists yet (I've no access to any Alphas anyway). I don't see how using quad_t would help in *your* case, on the other hand. -- Anatoly Vorobey, mellon@pobox.com http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message