2021.01.01 22:01 "Re: [Tiff] Enabling and requiring C99 language support", by Bob Friesenhahn

The main issue with !51 is this part of the public headers:

https://gitlab.com/libtiff/libtiff/-/blob/master/libtiff/tiff.h#L66

Here, we define the types int8, int16, int32, int64 and uint8, uint16, uint32, uint64. These don’t have a “tiff_" prefix and so have the potential to clash with other libraries which also define these types nonportably. Since this is now reported to happen in the real world, we do need to consider how to correct the problem.

If the problem (conflict) is well understood, then libtiff can take care to use the same underlying type as the conflicting definition so there is no error. The conflicting definition may or may not be the same as defined by stdint.h.

It is not necessary for the type names to be C typedefs. They can be defined via the C pre-processor instead so that they can be managed. The pre-processor is not quite as safe since it could overwrite some other symbol such as a variable name.

The problem we are reacting to was created long after libtiff used these typedefs.

Unfortunately, given that user code may be using these types, any change to the name would be a potential cause of breakage. Two options are to add the “tiff_" prefix to the types. Or if we require C99, to simply use the C99 int8_t … uint64_t types directly. Neither would avoid the need for a major version bump.

It is difficult to see how we can stop offering the un-scoped type names that libraries and apps using libtiff have been using for umpteen years because they were the documented interface. We can not expect all usages of libtiff to be prepared to adapt.

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