Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: unix question: files per directory
Keywords: how many can there be?
Message-ID: <1430@auspex.auspex.com>
Date: 12 Apr 89 18:24:31 GMT
References: <24110@beta.lanl.gov> <8420@xanth.cs.odu.edu>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Distribution: na
Organization: Auspex Systems, Santa Clara
Lines: 22

>Why was it decided that off_t should be signed?  Why should it not be
>unsigned long where unsigned longs are supported, or unsigned int where int
>is a 32 bit quantity?  It seems that signed long imposes an unnecessary
>2GB limit on file size.

And an unsigned long on a machine where that's 32 bits long imposes a
4GB limit on file size.  If 2GB is a limitation, I suspect 4GB will be
one shortly.... 

>And it doesn't make sense to have a negative offset into a file.  The
>only exception that comes to mind is that of returning an error code from
>a function like lseek(),

"lseek" also provides another exception.  Its second argument is an
"off_t", and since it can use that argument either as an absolute offset
in the file (i.e., relative to the beginning of the file) *or* as a
possibly-negative offset relative to the current position in the file or
to the end of the file, it has to be signed. 

Making "off_t" unsigned is a stopgap measure with its own problems.  If
(when) offsets > 2GB are needed, the fix will probably be to go to
64-bit offsets of some sort.