Sample Header Ad - 728x90

Why is off_t signed?

3 votes
2 answers
2032 views
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.
The only reason for 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