2004.09.15 15:02 "Re: [Tiff] Calltype support", by Bob Friesenhahn

This works perfectly, but has a great disadvantage: Migrating to a new version of the LibTiff is painful because we have to do the same work again.

Have you ever thought about adding calltype support, like the JPEGlib does? I think the readability of the code does not decrease. Or are there other (better?) ways to add calltype support?

I would agree that wrapping all the public definitions in appropriate macros is desirable and I do this on various other projects. Please submit a bug with the request.

However, isn't there a way to direct the compiler to use a particular calling convention that would avoid all this?

The only other means available appears to be to maintain a separate ".def" file to tell the linker which functions should be exported. This is very easy to implement but it adds another file to the build. I think that the user of the header files still needs to know which functions are imported from a DLL so that they use the right calling convention. This is painful for the library user.

I notice that for GraphicsMagick we have hacked our libtiff headers to declare functions like:

extern TIFFEXPORT tsize_t TIFFReadTile(TIFF*,
             tdata_t, uint32, uint32, uint32, tsample_t);

so that explicitly exporting functions is possible.

I therefore support adding the hooks to export functions under Windows, but don't think that obfuscating all function declaractions with macros is a necessary approach.

Bob

======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen