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-13 Guido U. Draheim |
The ProblemsMost of the problems around largefile support have already been discussed - and actually a long time ago. The largefile group (see the link in the left nav bar) had been active at around 1996, and there no more drafts or specs later on. It's all known. Well, not quite - a most people have not come aware of the problems. Some may have heard that it is possible to compile largefile applications with 64bit-off_t even on system that run otherwise as 32bit-off_t - however most will think that there are no serious problems about it. Here we hightlight some of those you'll run into when designing software. The first two entries handle size-mismatches that come from the fact when off_t has been used in public headers of a library or an application that can handle plugins. That's due to the fact that off_t is not anymore a constant-sized type at all types, it depends on the mode that a program has been compiled in. The latter section in this group points to the problem of filedescriptor inheritance - where a descriptor is shared among code expecting to work on 32bit-off_t-sized files at most while some other part freely runs across all boundaries as it is okay for largefile binaries. |