Is it safe to assign pos_type to uint64_t when dea

Question

When trying to deal with large files (2/4GB) in cross-platform manner, is it safe to cast pos_type to uint64_t?

• Platforms targeted: desktop machines running current Linux distro, Windows, Mac.
• Task: random binary file access (tellp and seekp).
• Sought: solution that is closest to the standards (POSIX, Win API), portable and safe.

Answer 1

In practice or in theory. As far as the standard is concerned, I don't think that there is a guarantee that pos_type is even convertible to an integral type; logically, it shouldn't be, since it contains several independent data: the offset from the beginning of the file and state information for multibyte decoding.

In practice, on the other hand, you shouldn't have any problems with Unix based machines; under Windows, the numeric value won't necessarily mean much if the file is opened in text mode, but you can convert a pos_type to a uint64_t and back without loss of value (unless there really is significant multibyte state in the original pos_type, but I don't know of any encoding under Windows where this would be the case).

It should be possible to determine at compile time whether pos_type will convert implicitly to an integral type or not, and use this in some sort of static_assert. I don't think this buys much, however; it won't determine whether the integral value is in any way usable except to reconvert back to a pos_type. (It might be some sort of magic cookie, for example. But I wouldn't worry about it too much. The standard allows a lot of things that no reasonable implementation will do. Just keep in mind that even under Windows, the value doesn't always represent the exact number of bytes which can be read.