Messages in this thread |  | | | Date | 22 Dec 1999 01:26:00 +0200 | | From | (Kai Henningsen) | | Subject | Re: Ok, making ready for pre-2.4 and code-freeze.. |
| |
R.E.Wolff@bitwizard.nl (Rogier Wolff) wrote on 21.12.99 in <199912211629.RAA18130@cave.bitwizard.nl>:
> 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/
|  |