2021.01.01 19:31 "[Tiff] Enabling and requiring C99 language support", by Roger Leigh

Hi folks,

There is ongoing discussion of this on:

• !51 <https://gitlab.com/libtiff/libtiff/-/merge_requests/51> (older MR which was closed, relating to use of "long long" vs "long”)
• !185 <https://gitlab.com/libtiff/libtiff/-/merge_requests/185/diffs> (new MR to enable C99 support without any compatibility break)

For anyone who isn’t following the discussion of the above, this is to bring it to a wider audience.

The main question to address is: how far can we go in switching over to C99?

• Do we stop at !185 and leave all the compatibility logic in place?
• Do we remove pre-C99 support and require stdint.h and inttypes.h?
• Do we remove the nonportable typedefs as well?

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.

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.

Kind regards,

Roger