Re: small bug in memory_lseek()

David Wragg (dpw@doc.ic.ac.uk)
Thu, 12 Feb 1998 20:02:56 GMT

Michael Elizabeth Chastain writes:
> Hi Dave,
>
> > In memory_lseek() in drivers/char/mem.c, the code to stop successful
> > seeks on negative offsets giving what look like error returns (as
> > described in the comment) is never reached. A patch to fix this
> > follows.
>
> [snip]
>
> if (lseek(pi->fd, (off_t) memaddr, 0) == (off_t) memaddr)
>
> I believe that if gdb were enabled to use procfs on Linux,
> it would rely on the existing negative-return-value-for-negative-argument
> semantics.
>

Hmmm.

The gdb code above lseeks within /proc/nnnn/mem, which is handled by
mem_lseek in fs/proc/mem.c. It produces the same dilemma as the code
in dribers/char/mem.c though, and they ought to behave consistently.

When I noticed the problem in memory_lseek(), I thought the comment
was right and the code was wrong, but the situation is clearly more
complicated than that.

Although code like:

if (syscall(...) < 0) {
/* Failed syscall, ho hum. */

is common, for syscall = open, read, write, ..., I think that code is
really broken for syscall = lseek. In this case, when the
documentation says "lseek() returns (off_t)-1 on error", it really
means an "if and only if". So perhaps memory_lseek() should only remap
a resulting offset of -1 to 0, rather that any negative value.

And those who go around lseeking to (off_t)-1 get what they deserve
:-)

Does anyone know how other systems behave? Any other bright ideas?

--
Dave Wragg




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu