On my journey to create a 16 EiB sized file,
I encountered the following issue:
POSIX defines files to have their size represented using type
off_t
,
and that "**blkcnt_t** and **off_t** shall be signed integer types."
According to unistd.h , _POSIX_V7_LP64_OFF64
requires 64-bit off_t
types, while _POSIX_V7_LPBIG_OFFBIG
allows for larger ones:
>_POSIX_V7_LP64_OFF64
-
The implementation provides a C-language compilation environment with 32-bit **int**
and 64-bit **long**, **pointer**, and **off_t** types.
_POSIX_V7_LPBIG_OFFBIG
-
The implementation provides a C-language compilation environment with an **int** type using at least 32 bits and **long**, **pointer**, and **off_t** types using at least 64 bits.
off_t
being signed is its use in lseek
and fseek , where the formal argument offset
can be used to specify the file offset relative to some other value,
if whence
is set to either SEEK_CUR
or SEEK_END
.
To me, this seems odd, as I can't imagine this case to be worth wasting half of the usable range for the file size,
since any code relying on this feature could easily be rewritten to request the current absolute offset, add/subtract the relative offset and then seek to this calculated value.
Are there any other reasons for POSIX to specify off_t
to be a signed type?
## UPDATE
I noticed that the UNIX PROGRAMMER’S MANUAL (TYPES ( 5 )
, Seventh Edition, Volume 1
January, 1979) defined off_t
to be a long
:
> typedef long off_t;
Though, when digging further, I found FSEEK ( 3S )
to reveal it being used as signed long
as well:
fseek(stream, offset, ptrname)
FILE *stream;
long offset;
> Fseek sets the position of the next input or output operation on the stream. The new position is at the
signed distance offset bytes from the beginning, the current position, or the end of the file, according as
ptrname has the value 0, 1, or 2.
Asked by Semnodime
(397 rep)
May 7, 2024, 01:42 PM
Last activity: May 8, 2024, 01:02 AM
Last activity: May 8, 2024, 01:02 AM