This section is largely included to discuss some other variants to support largefile variants in a system. And why they deem inferior actually. Nethertheless, they have their use case and if you happen to have that situation then you might just want to know about them. Otherwise look at the previous section how to defend against improper usage on 64on32.
The first variant is seen in zlib 1.2.x code (by dec03). I have once
mailed the maintainers (without any response) that zlib is off_t-sensitive
through its API entries gzseek, gztell and gzopen. A year later they
come up with a solution, but neither using
twinlibs or a dualmode or adding
simply some defence #ifdefs. Instead
we have a new API entry call named "zlibCompileFlags".
If you look closer at the description, you see that third party code can check bits 7/6 of the returnvalue which off_t type the zlib variant assumes. If it does not match (at runtime!) then the third party code can graciously bail out before doing anything wrong to the system (like accessing large files). The check is as easy as
if (zlibCompileFlags()&(128+64)!=sizeof(off_t)<<4) {
syslog(LOG_ERR, "off_t mismatch of mylib with zlib"); exit(1); }
Now, you may guess how many application writers will actually use that. I don't expect any unless it is itself a platform library that is geard to cover system portability roughness. Also, it is dubious where an error message needs to pop up, perhaps it should be a gui dialog for a gui application but how do you open that when you are still in the init()-path of the application and want to bail out?
Another interesting variant can be seen in latest contribution of aio_* calls to linux (i.e. asynchronous io). Have a look at aio.h, and have a look at the structures - there you see this:
/* Asynchronous I/O control block. */
struct aiocb
{
[....]
#ifndef __USE_FILE_OFFSET64
__off_t aio_offset; /* File offset. */
char __pad[sizeof (__off64_t) - sizeof (__off_t)];
#else
__off64_t aio_offset; /* File offset. */
#endif
char __unused[32];
};
/* The same for the 64bit offsets. Please note that the members aio_fildes
to __return_value have to be the same in aiocb and aiocb64. */
#ifdef __USE_LARGEFILE64
struct aiocb64
{
[....]
I do better leave that uncommented, it does however show you the problems that you may run up if you want to provide a real dualmode lib that is resistant even to largefile problems with off_t embedded in control structures modifiable by user code that is possible compiled differently and possibly moved to a system where the runtime library happens to be even in a different largefile mode than expected on the build host. Now, what do you expect the logic to be in the implementation code...