Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.bugs.sys5
Subject: Re: Possible "lseek()" bug (Clarification)
Message-ID: <6863@brl-smoke.ARPA>
Date: 18 Dec 87 22:00:47 GMT
References: <716@hsi.UUCP> <36212@sun.uucp> <978@sauron.Columbia.NCR.COM> <1655@desint.UUCP> <986@sauron.Columbia.NCR.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 10
Keywords: lseek

In article <986@sauron.Columbia.NCR.COM> campbell@sauron.Columbia.NCR.COM (Mark Campbell) writes:
>In the AT&T 3B2 V.3.0 and V.3.1 code *THERE IS NO CLAUSE* which tests for a
>negative offset.

My guess (having not yet received our SVR3 source tape) is that the
file system code itself (on the "back end" of the file system switch)
now performs this test.

Try the simple experiment of seeking to a negative offset on a local
ordinary file on a vanilla SVR3 system and see what happens.