campbell@sauron.Columbia.NCR.COM (Mark Campbell) (12/15/87)
It seems that the V.3.1 "lseek()" does not return a negative value when asserted with a negative offset. There is some talk in the manual concerning this behavior with remote file systems; however, this problem appears when accessed local file descriptors too. Is there something I'm missing? -- Mark Campbell m.campbell@ncrcae.Columbia.NCR.COM
geoff@desint.UUCP (Geoff Kuenning) (12/16/87)
In article <978@sauron.Columbia.NCR.COM> campbell@sauron.Columbia.NCR.COM (Mark Campbell) writes: > It seems that the V.3.1 "lseek()" does not return a negative value when > asserted with a negative offset. There is some talk in the manual concerning > this behavior with remote file systems; however, this problem appears when > accessed local file descriptors too. > > Is there something I'm missing? That's what it's supposed to do. From the manual page for lseek(2): RETURN VALUE Upon successful completion, a non-negative integer indicating the file pointer value is returned. Otherwise, a value of -1 is returned and errno is set to indicate the error. -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
campbell@sauron.Columbia.NCR.COM (Mark Campbell) (12/17/87)
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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/19/87)
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.
jh@pcsbst (12/21/87)
We at PCS ran into this problem, too. This is because system addresses in /dev/kmem (maybe /dev/mem) may look like _entry: 0x80000400 Thus, e.g. programs like crash, ps, who etc. have to lseek(corefd, nlist[PROC].n_value, 0); cannot accept an error return. How should one fix this? We opened the respective addresses for character special files. Johannes Heuft unido!pcsbst!jh
larry@hcr.UUCP (Larry Philps) (12/30/87)
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