> Tigran Aivazian wrote:
> > On Tue, 21 Dec 1999, Rogier Wolff wrote:
> > > Tigran Aivazian wrote:
> > > > > The return code for unix system calls should be defined as
> > > > > "negative" for error, and not "-1".
> > > >
> > > > I beg to differ because lseek(2) has the right to return negative
> > > > offsets on some implementations (of UNIX) on some architectures
> > > > (notably i386).
> > >
> > > I beg to differ: lseek has no right to return a position before the
> > > start of the file.
> > >
> > > * Upon successful completion, lseek returns the resulting
> > > * offset location as measured in bytes from the beginning of
> > > * the file.
> > >
> > > Maybe, some OSes are "breaking the rules" a bit by allowing larger
> > > files than a 31-bit return value for lseek(2) allows, but that's their
> > > problem.
> >
> > Dear Rogier,
> >
> > have a look at Stevens' APUE, the page that describes lseek(2) (it is not
>
> Sorry, I don't have that book. I only have TCP/IP illustrated Part 1.
p.52/3 "Normally, a file's current offset must be a nonnegative integer.
It is possible, however, that certain devices could allow negative
offsets. But for regular files the offset must be nonnegative.
Since negative offsets are possible, we should be careful to
compare the return value from lseek as being equal to or not equal
to -1 and not test if it's less than 0.
The /dev/kmem device on SVR4 for the 80386 supports negative
offsets."
However, I'd rather look at the Single Unix def:
[...]
off_t lseek(int fildes, off_t offset, int whence);
[...]
RETURN VALUE
Upon successful completion, the resulting offset, as measured in
bytes from the beginning of the file, is returned. Otherwise,
(off_t)-1 is returned, errno is set to indicate the error and the
file offset will remain unchanged.
ERRORS
The lseek() function will fail if:
[...]
[EOVERFLOW]
The resulting file offset would be a value which cannot be
represented correctly in an object of type off_t.
[...]
Nothing about negative or nonnegative here. But note the cast to off_t.
So let's look at what it says about off_t:
[...]
sys/types.h - data types
[...]
off_t
Used for file sizes.
[...]
All of the types are defined as arithmetic types of an appropriate
length, with the following exceptions: key_t, pthread_attr_t,
pthread_cond_t, pthread_condattr_t, pthread_key_t, pthread_mutex_t,
pthread_mutexattr_t, pthread_once_t, pthread_rwlock_t and
>> pthread_rwlockattr_t. Additionally, blkcnt_t and off_t are
extended signed integral types, fsblkcnt_t, fsfilcnt_t and ino_t
are defined as extended unsigned integral types, size_t is an
unsigned integral type, and blksize_t, pid_t and ssize_t are signed
integral types. The type ssize_t is capable of storing values at
least in the range [-1, SSIZE_MAX]. The type useconds_t is an
unsigned integral type capable of storing values at least in the
range [0, 1,000,000]. The type suseconds_t is a signed integral
type capable of storing values at least in the range [-1,
1,000,000].
[...]
Huh. "extended signed integral type"? There's a glossary:
[...]
extended signed integral type
A signed integral type or an implementation-dependent type with
similar properties.
[...]
extended unsigned integral type
An unsigned integral type or an implementation-dependent type with
similar properties.
[...]
Oh, ok: it might be "long long". But it seems the cast doesn't actually do
anything ...
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/