|go text: || - index - problems - systems - libraries - converting - programming - [ old library ] - new library - links -
||topics: || - dualmode renames - the extra function - largefile64_source - glibc headers - libgz example *** -

Old Compatible Libraries

Extending an old libary design to be ready for largefile64 can look embarassing at first sight. Some people will try to use twinlibs - however modifying the library into a dualmode implementation is easier than you might think initially. The following pages will provide you with template code that you can take over to get started with a dualmode implementation.

The first step - of course - is to identify all functions that you like to be provided twice on a 64on32 system. This is almost easy as them are simply all functions that take "off_t" as an argument or that have "off_t" as a return value. For structures declations however you can not do much - it's simply more complicated. For all functions being declared with off_t you need to make sure that in the case of a 64on32 system they should be renamed so that the original 32bit calls can attach to the old non-largefile function name.

The second step - be aware of that - is to add configure checks that detect the problematic case of a 64on32 system. That is almost easy as well - for the autoconf case you could reuse the macro AC_SYS_LARGEFILE_SENSITIVE. If you are not using autoconf then you can create your own check - have a test program that compiles "off_t" with _FILE_OFFSET_BITS=64 and count the byte-length (i.e. C's "sizeof off_t"). Then make a test program that prints the byte-length of "long" (i.e. C's "sizeof long") and if the two results differ then you have largefile-extended 64on32 system.

In the final steps you need to add dualmode implementatio part and clutter your headers with the required ifdef series. It's not that complicated to write but it is a little harder to read - that is one of the reasons why the dualmode implementation approach is harder to maintain. The other is that most of your unit tests will only target one of the implementations - either 32bit off_t or 64bit off_t - but not both of them. Setting up a sophisticated test environment that can cope with both, well, that is possible but is is just as it is attributed - being connected to an effort on getting "sophisticated".