2021.01.06 14:15 "Re: [Tiff] Motions related to C99 use in libtiff", by Bob Friesenhahn

As long as the C99 data types correspond to the custom typedefs, won't the ABI remain the same?

Would temporarily freezing the last pre-C99 ABI help with the transition?

If Motion 2 includes C99 printf formats, is it worth separating that out?

Where ABI implies that existing dependent binaries continue to run, then the C ABI should usually remain the same. However, in C/C++, types of the same size are not actually the "same" so 'long' and 'long long' are different at a language level. In C++ the type is encoded into the function, method, and class signature so if any C++ code is re-using the type names that libtiff declares as part of their interfaces (including members of C++ class definitions), then the compiled result may be different (e.g. would no longer link or be compatible as a shared library with already compiled code) after the C99 switch.

Some 64-bit systems chose 'long' for their int64_t type and others chose 'long long'. Sometimes the choice was based on the original implementor's feelings but other times it has to do with the legacy from a 32-bit version of the OS where 'long' was already used in frozen interface definitions.

In Microsoft Windows 64-bit ABI, a 'long' remains 32-bits just like an 'int'. In 64-bit Linux (and most other Unix systems), a 'long' is normally promoted to 64-bits.

Libtiff always used 'long' for its 64-bit type if it was 64-bits. Libtiff4 needed a 64-bit type in order to support the BigTIFF format since it supports 64-bit offsets.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt