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) 2010-03-27 Guido U. Draheim |
long32 on 64With all the compat32 calls in place (and not moving them to a seperate library) one could even get an easy approximate of the dualmode library model. It is just the other way round in that calls that are NOT largefile64 should be diverted to their suffix32 variants. While this is requires some #ifdefs the actual structure is a lot easier to maintain that the original dualmode - see for yourself: #if defined _LARGEFILE_SOURCE extern off_t myseek(int fd, off_t pos, int whence); #elif defined _LARGEFILE64_SOURCE extern off64_t myseek(int fd, off64_t pos, int whence); #else #define myseek myseek32 #endif The reasoning behind this: if the application developers goes for either of _LARGEFILE_SOURCE or _LARGEFILE64_SOURCE then they want to access the largefile64 implementation that the library was actually compiled with. If neither is used then it is asserted that "off_t" and "long" are the same, so one can divert the call to the compat32 call that is based on "long". Essentially, no call frame mismatch can occur anymore but the non-compat32 functions are preferred for any code that cares. If an application developers is unsure whether the code is ready for _LARGEFILE_SOURCE and choose _LARGEFILE64_SOURCE whereby using your largefile64 libary only by use of "off64_t" arguments. Of course the library writer could be even harder than that - like removing the final #define-diversion and forcing non-largefile applications into using the compat32 functions explicity. A medium variant would be to use the deprecation feature of most of the modern compilers, e.g. with gcc this is #else inline long myseek(int fd, long pos, int whence) __attribute__((deprecated)) { return myseek32(fd, pos, whence); } #endif This gives a nice warning to the application developers - and it saves the library creator from answering questions like "I get errors from your library but it was supposed to have that function". After all, the 64on32 model has been achieved by pushing a long32 call on top of the only 64-bit file offsets implementations to exist. Only one compilation variant needs to be maintained then. |