From owner-freebsd-hackers Sun Nov 12 15:18:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA10065 for hackers-outgoing; Sun, 12 Nov 1995 15:18:28 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA10058 for ; Sun, 12 Nov 1995 15:18:23 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id KAA26938; Mon, 13 Nov 1995 10:16:50 +1100 Date: Mon, 13 Nov 1995 10:16:50 +1100 From: Bruce Evans Message-Id: <199511122316.KAA26938@godzilla.zeta.org.au> To: bakul@netcom.com, hasty@rah.star-gate.com Subject: Re: linux's lseek vs freebsd's lseek Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> (int)fp->f_offset += (int)uap->offset; >> ^^^^ ^^^^ >> The question is what is the implication of doing a signed addition as >> supposed to an unsigned addition as it is in the original file. >Huh? f_offset & uap->offset are of type quad_t, which is a >signed quantity and -ve offsets are perfectly reasonable >when you seek relative to file-end or current-position. POSIX requires off_t to be a signed arithmetic type so that negative offsets work right. In the above, the cast to (int) on the RHS throws away the top 32 bits on the i386, so seeking back 1 would actually seek forward 0xffffffff, while the cast to (int) on the LHS shouldn't compile. Bruce