>Number:         597
>Category:       port-sparc
>Synopsis:       SunOS lseek() not fully emulated
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 29 13:35:02 1994
>Originator:     der Mouse
>Organization:
	Me?  Surely you jest.
>Release:        NetBSD/sparc 1.0
>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
>Audit-Trail:
>Unformatted: