From owner-freebsd-hackers  Sun Nov 12 13:08:12 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id NAA08673
          for hackers-outgoing; Sun, 12 Nov 1995 13:08:12 -0800
Received: from netcom22.netcom.com (bakul@netcom22.netcom.com [192.100.81.136])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA08628
          for <hackers@freebsd.org>; Sun, 12 Nov 1995 13:08:07 -0800
Received: from localhost by netcom22.netcom.com (8.6.12/Netcom)
	id NAA21837; Sun, 12 Nov 1995 13:06:37 -0800
Message-Id: <199511122106.NAA21837@netcom22.netcom.com>
To: "Amancio Hasty Jr." <hasty@rah.star-gate.com>
cc: hackers@freebsd.org
Subject: Re: linux's lseek vs freebsd's lseek 
In-reply-to: Your message of "Sun, 12 Nov 95 12:43:37 PST."
             <199511122043.MAA01434@rah.star-gate.com> 
Date: Sun, 12 Nov 95 13:06:36 -0800
From: Bakul Shah <bakul@netcom.com>
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.