Path: utzoo!lsuc!hcr!larry
From: larry@hcr.UUCP (Larry Philps)
Newsgroups: comp.bugs.sys5
Subject: Re: Possible "lseek()" bug (Clarification)
Message-ID: <3035@hcr.UUCP>
Date: Wed, 30-Dec-87 09:11:28 EST
Article-I.D.: hcr.3035
Posted: Wed Dec 30 09:11:28 1987
References: <716@hsi.UUCP> <36212@sun.uucp> <978@sauron.Columbia.NCR.COM> <1655@desint.UUCP> <986@sauron.Columbia.NCR.COM>
Reply-To: larry@hcr.UUCP (Larry Philps)
Organization: HCR Corporation, Toronto
Lines: 32
Keywords: lseek

In article <986@sauron.Columbia.NCR.COM> campbell@sauron.Columbia.NCR.COM (Mark Campbell) writes:
> ...
>In the AT&T VAX V.2.2 code there is a clause in the "seek" routine which tests
>for a negative offset and returns "EINVAL" if it finds that negative offset.
> ...
>In the AT&T 3B2 V.3.0 and V.3.1 code *THERE IS NO CLAUSE* which tests for a
>negative offset.  Thus it is possible to issue the "lseek()" system call with
>a negative offset and have the system call return that negative offset, e.g.,
>asserting "lseek()" with "whence" set to 0 and the offset set to -5 causes
>a -5 value to be returned.

Have you actually tried to issue that lseek call?

In V.3.0 and above System V contains a File System Switch that allows the file
system calls to work on multiple file system types at one time.  In the case
of most V.3 systems at the moment, the two file systems defined -- "s5" (The
System V File system) and "du" (the RFS File system).  Now negative seeks are
supposed to fail on "s5" files, but, as you have noted from the documentation,
must work on "du" files.  Thus AT&T did the obvious thing and moved the test
for negativity from the common "seek" routine to the "s5" specific "s5notify"
routine.  Look in there you will find the missing test.  The corresponding
routine for RFS, "dunotify", does not have the test.  Thus the semantics are
correct for both types of file systems.

---
Larry Philps
HCR Corporation
130 Bloor St. West, 10th floor
Toronto, Ontario
M5S 1N5
(416) 922-1937
{utzoo,utcsri,decvax,ihnp4}!hcr!larry