4 ms·
You didn't understand. Consistent use of one (unsigned) type for lengths would avoid issues because there'd be no casts. off_t is signed and doesn't make sens
by adobriyan 15y ago
You didn't understand.
Consistent use of one (unsigned) type for lengths would avoid issues because there'd be no casts.
off_t is signed and doesn't make sense because file length can't be negative.
- adobriyan 15y agoIn fact existence of off64_t proves off_t is not OK.
- tedunangst 15y agoThe existence of off64_t proves Linux fucked up. It's not a standard type and other operating systems don't have it.
- acqq 15y ago> off_t is signed and doesn't make sense Wrong, it's used to seek in both directions in calls where direction is signed by... a sign! http://www.unix.com/man-page/POSIX/3posix/lseek/ http://www.unix.com/man-page/POSIX/3posix/lseek/
- adobriyan 15y ago[slowly] off_t is wrong for maintaining length because off_t is signed and lengths are fundamentally unsigned. Signed offset is OK for seeking.
- JoachimSchipper 15y agoIndeed, consistent use of one type for lengths avoids issues because you need no casts. For in-memory data, the type to use is size_t since that is what e.g. memcpy(), strncmp() and read() accept; for a position in a file or a file length, off_t is a better choice, since that is what pread(), lseek() and stat() use. I'm a fan of unsigned data types in general, but using off_t for file lengths is the way to go. (It's not like you need defined overflow semantics for file positions, anyway.) (You don't need off64_t if you compile with the proper #defines, which you should do on Linux.)