Structure Mismatch

The 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.