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 |
Structure MismatchThe structure mismatch problems are a bit more hidden than those of a mere Callframe Mismatch. In many cases, you will not have a chance to see directly, only with seeing variables being corrupted mysterously. Let's suppose there is a header file containg the following: struct callback { int file; off_t pos; int values[4]; }; Now, this structure will be usually build within the library code itself returning an allocated structure of the given type. And this library-allocated structure will also be passed as a handle back through other library API calls. So far so fine. However, what if the application wants to quickly access/modify a value within this structure - and possibly that is even required by the programming scheme suggested by the library maker. Be known that a lot library headers exist that make up just a define like #define get_callback_pos(handle) \ (((struct callback*)(handle))->pos) so that the application writer will think that the access to this struct-member has been hidden in a library method, where in fact it isn't. Now, from here it is easy to guess what happens when the application and library are compiled with different off_t-defines making one to assume 32bit-off_t and the other having 64bit-off_t. On little-endian machines it is even not likely that there are problems on accessing "pos", it will actually result in spurious problems as the access to the "values"-array is off by one. Now, just try to track these, should there be a bug report about them. Even more suble than that - function callbacks registered in a structure: struct callbacks { off_t (*io_seek)(int fd, off_t offs, int whence); }; and let the usage protocol to define that the application code is allowed/supposed to change a callback in this structure to define a different behaviour of the library called. Furthermore, let's assume the application code uses the system-wide routine called "lseek" from the C library. No, it does not work. When 64bit-off_t application modifies the "io_seek" callback with the system's "lseek" it will actually put the entry address of a symbol otherwise known as "lseek64". The library however might be expecting 32bit-off_t - and therefore build a mismatching callframe for the callback. And no, the C compiler will not warn at that since the call-synopsis of "io_seek" does exactly match that of "lseek64" - for off_t is off64_t in the application. There is no real help in that - one should better try to avoid it. |