Re: cvs commit: src/sys/kern kern_lockf.c

:>   off_t is a signed value.  The last commit caused the kernel to fail with
:>   a end < start panic.
:>   
:>   Revision  Changes    Path
:>   1.23      +1 -1      src/sys/kern/kern_lockf.c
:> 
:> http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_lockf.c.diff?r1=1.22&r2=1.23&f=u
:> 
:
:This was found by me while porting this change over to FreeBSD. In
:FreeBSD, there was a case where 
:
: start	= 0xffffffff 
: end	= 0x7fffffff
:
:Thus, my FreeBSD 6-CURRENT kernel was panicking with start > end.
:
:Joerg suggested that this might be a macro error. Patching the tree with
:ULLONG_MAX seemed to fix the error, but now I'm getting it again. I'll
:switch the commit back in my Perforce branch and re-report. This is very
:odd.
:
:--Devon

    I don't know what the standard says but off_t is definitely signed, 
    and I was fairly certain that lockf allows a signed range, including
    negative numbers.

    sys/_types.h:typedef    __int64_t       __off_t;        /* file offset */

    These are also be 64 bit ints.  Are you sure the values you
    saw where:

: start	= 0xffffffff 
: end	= 0x7fffffff

    And not:

start	= 0xffffffffffffffff 
end	= 0x7fffffffffffffff

    I the values you saw were truncated to 32 bits, then perhaps there is
    a bug in the code somewhere which is truncating parts of the range to
    a 32 bit integer and causing 'start' to be 0xffffffff (which is 4GB)
    instead of 0xffffffffffffffff (which is -1).

					-Matt
					Matthew Dillon 
					<[e-mail]>