Subject: port-sparc/597: SunOS lseek() not fully emulated
To: None <>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: netbsd-bugs
Date: 11/29/1994 13:35:03
>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
	Me?  Surely you jest.
>Release:        NetBSD/sparc 1.0
	SPARC IPC, but it doesn't matter
	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.
	sunos% cat x.c
	#include <errno.h>
	#include <sys/file.h>
	  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
	(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
	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