3 ms·
IMHO, size_t (for in-memory objects) or off_t (for files) makes more sense. That is not the issue here, though: casting longs to ints would cause trouble even
by JoachimSchipper 15y ago
IMHO, size_t (for in-memory objects) or off_t (for files) makes more sense.
That is not the issue here, though: casting longs to ints would cause trouble even if both are unsigned.
- adobriyan 15y agoYou 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.)