NetBSD Problem Report #597

From gnats  Tue Nov 29 13:31:49 1994
Received: from Collatz.McRCIM.McGill.EDU (Collatz.McRCIM.McGill.EDU [132.206.78.1]) by sun-lamp.cs.berkeley.edu (8.6.9/8.6.9) with ESMTP id NAA08933 for <gnats-bugs@sun-lamp.cs.berkeley.edu>; Tue, 29 Nov 1994 13:31:38 -0800
Message-Id: <199411292133.QAA12397@Collatz.McRCIM.McGill.EDU>
Date: Tue, 29 Nov 1994 16:33:18 -0500
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
Reply-To: mouse@Collatz.McRCIM.McGill.EDU
To: gnats-bugs@sun-lamp.cs.berkeley.edu
Subject: SunOS lseek() not fully emulated
X-Send-Pr-Version: 3.2

>Number:         597
>Category:       port-sparc
>Synopsis:       SunOS lseek() not fully emulated
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gnats-admin
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 29 13:35:02 +0000 1994
>Closed-Date:    Fri Jun 20 19:24:28 +0000 1997
>Last-Modified:  Fri Jun 20 19:25:15 +0000 1997
>Originator:     der Mouse
>Release:        NetBSD/sparc 1.0
>Organization:
	Me?  Surely you jest.
>Environment:
	SPARC IPC, but it doesn't matter
>Description:
	Some lseek() calls that produce EINVAL on SunOS will succeed
	under NetBSD's SunOS emulation.  Whether this is actually a
	problem or not is debatable.
>How-To-Repeat:
	sunos% cat x.c
	#include <errno.h>
	#include <sys/file.h>
	main()
	{
	  int error, offset;
	  offset = (int)lseek(open("/vmunix",O_RDONLY,0),-2L,L_SET);
	  error  = errno;
	  printf("Offset: %d; Errno: %d\n",offset,error);
	}
	sunos% cc -Bstatic -o x x.c
	sunos% x
	Offset: -1; Errno: 22
	sunos% 
	(copy the above-generated binary to a NetBSD/sparc machine, and
	make a symlink from /vmunix to somewhere openable)
	netbsd% x
	Offset: -2; Errno: 0
	netbsd% 
>Fix:
	I'm not sure this really needs fixing.  I doubt very many
	programs depend on getting errors like this, though following
	this with an L_INCR seek will end up leaving the file pointer
	at a "wrong" place.  If it does need fixing, either fix
	olseek() to do proper checks or introduce a sun_lseek(),
	depending on whether old 32-bit NetBSD lseek calls should be
	changed too.  I'm also not sure exactly what criteria SunOS
	places on the offset, though some simple experiments make me
	think that any offset with the high bit set is bounced.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: lukem 
State-Changed-When: Thu Jun 19 22:28:10 PDT 1997 
State-Changed-Why:  
I think Klaus Klein fixed the NetBSD lseek() a while ago to prevent -ve 
offsets (or to error as per POSIX). Has this resulted in your bug being fixed? 
State-Changed-From-To: feedback->closed 
State-Changed-By: mouse 
State-Changed-When: Fri Jun 20 12:24:28 PDT 1997 
State-Changed-Why:  
This seems to have been fixed, probably by kleink's POSIXification 
of lseek-to-negative-offsets. 
>Unformatted:

Home	PR Database Search