🚀 go-pugleaf

> Repeat-By:
> 	nawk '{printf("%s%s", "hi")}'       (then enter a return)
> 
> 		This causes a core dump on a VAX running 4.3 BSD.

Fixed in the S5R3.1 version.  The code there is different (I assume that the
routine you fixed here is "error" in "lib.c"); "error" takes a potload of
arguments and passes them, along with "s", to "fprintf".
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com

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

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

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

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.

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