index -summary -history -testscript perl / python problems -with callframes -with structures -largefile seeks -broken builds systems -freeBSD/darwin -linux/solaris -64on32 mix -distro makers -win32/other (2) libraries - libc ..(3264)
- zlib ..(-32-)
- gtk2 ..(-64-)
converting -old non-off_t code -going largefile -longlong default -face dualmode -make twinlibs -and defend (it) programming -largefile default -off_t in headers -make export64 -find mismatch -the autowrappers -environ changes -best practice? old library -dualmode renames -the extra function -largefile64_source -glibc headers -libgz example *** new library -dual export -largefiles win32 -compat32 calls -compat32 library -long32 dualmode links -some quotes -sitemap / mpl -large.file Group* -ac-archive Site*
(C) 2002-01-26 Guido U. Draheim |
Win32 / Other / Older Systems
A talkback to the
freshmeat article did ask:
This is actually quite right - the win32-API provides a different `transitional API` to support 64bit file-access for applications using lseeki64/telli64/fstati64. Note the "i64" suffix instead of the "64" suffix in the unix `transitional API`. That's perhaps due to the fact that the win95/nt APIs were defined before the unix98 APIs were discussed. The win32-API does not use off_t for the file-access methods, and it uses plain `long` instead, - just like the old unix systems will do. Even with the widespread adoption of off_t, Microsoft did never change its APIs by introducing a `typedef long off_t` around. Even today the win32-API shows usage of `long` for lseek/tell/stat functions (those w/o i64)
That makes win32 immune to dualmode problems, and the absence of
`off_t` makes it even inappropriate to add a shapeshifting -Define
somewhere that could make magically standard posixish programs to use
64bit file-offsets on platforms being otherwise 32bit. At the same time,
I can not recall any contemporary unix-compatible system that is
missing the `off_t` typedef, even that such is not impossible in theory -
see autoconf To get to the point - I do not expect any programmer to use the `transitional API` directly, suddenly using tell64/telli64 directly. The off_t magic allows to run 64on32 with just a -Define, one should just care to add that -Define everywhere. That will make the software still compatible with very old system that do not use 64bit file-access internally, however it does also make it use plain 32bit file-access on those systems that did never introduce off_t, thereby missing the chance to change the default sizeof off_t later. Note however that the unix98 largefile spec allows to do the same as on win32 - simply define -D_LARGEFILE64_SOURCE - which will make the 64bit file-calls to get visible (normally they are suppressed to not pollute the application namespace). Then you can declare variables of type "off64_t" and call functions like lseek64/tell64/fstat64 with these entities. However, portable software would then need to deploy a lot of #ifdef's around to select either of lseek/lseek64 calls. That's what the 64on32 typeshifting is about where the #ifdef's are put out into the system headers. |