> If I'm not mistaken, it goes like this...

>> off_t lseek(int fildes, off_t offset, int whence)
>                          ^^^^^
>                         64 bits

>>  offset = (int)lseek(open("/netbsd", O_RDONLY, 0), -2L, SEEK_SET);
>            ^^^^^                                    ^^^
>           32 bits                                 32 bits

That was my reaction too.  But there were a handful of #include files,
and if one of 'em provides a prototype for lseek, these differences are
irrelevant.

So I compiled it as given and ran it under trc.  Sure enough....

open (0x2948="/netbsd", 0x0=O_RDONLY) = 3
lseek (3, (0,) <0xffffffff, 0xfffffffe>=-2, 0x0=L_SET) = <0xffffffff, 0xfffffffe>=-2
fstat (1, 0xf7fff238) = 0
__sysctl (0xf7fff228=<6,7>=<HW,PAGESIZE>, 2, 0xf7fff224, 0xf7fff220=4, 0x0, 0) = 4: value=4096
obreak (0xcd30) = 0
obreak (0xcffc) = 0
obreak (0x11ffc) = 0
write (1, 0xd000="Offset: -2; Errno: 0\n", 21) = Offset: -2; Errno: 0
21
exit (1) = [exited with status 1]

So that's not the problem.  Go read lseek() in /sys/kern/vfs_syscalls.c
and you'll see that it has absolutely no checks on the offset argument,
just copying it blindly into the file pointer.

> It looks like it's a bug in your program to me...

> Have you tried:
>   offset = (off_t)lseek(open("/netbsd", O_RDONLY, 0), (off_t)-2, SEEK_SET);
> ??

No, because syscall tracing indicates that's what's happening.  Did
_you_ try it?  I doubt it.  (Of course, the assignment to "offset"
includes an implicit cast to int, since offset is int.  If you want to
be fully careful, declare offset as off_t and print it with %qd.)

I've now tried it myself.  Same results.  Sorry. :-)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu