Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ames!sdcsvax!ucsdhub!hp-sdd!ncr-sd!ncrcae!sauron!campbell From: campbell@sauron.Columbia.NCR.COM (Mark Campbell) Newsgroups: comp.bugs.sys5 Subject: Re: Possible "lseek()" bug (Clarification) Message-ID: <986@sauron.Columbia.NCR.COM> Date: 17 Dec 87 13:08:01 GMT References: <716@hsi.UUCP> <36212@sun.uucp> <978@sauron.Columbia.NCR.COM> <1655@desint.UUCP> Reply-To: campbell@sauron.Columbia.NCR.COM (Mark Campbell) Organization: Entry Level Systems Development, NCR Corp., Columbia, SC Lines: 28 Keywords: lseek Okay, I've gotten several replies to this and none have addressed the problem. I know that there is a lot of noise on the net (I've generated a bit myself); thus I'll try to present it more clearly. 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. This is documented, and both the SVID and X-OPEN standards lead you to believe that this is correct (some small interpretation is necessary). 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. Now the simple solution would be to simply insert the negative offset test clause in the V.3.1 "seek()" code. What troubles me is that the V.3 documentation cites the case of negative offsets being allowed if the file descriptor is remote. I'm afraid of hindering future AT&T compatibility by inserting this clause. I'd appreciate any and all response to this. I've got several well-known test suites which use the negative offset feature of V.2.2 "lseek()" to verify correct "lseek()" behavior and would like to either fix the code or reject this part of those suites. Thanks. -- Mark Campbell m.campbell@ncrcae.Columbia.NCR.COM