RFC 95: Use standard C/C++ integer types (proposed, NOT adopted)
even.rouault @ spatialys.com
Proposed, but not adopted
This RFC replaces the use of the custom integer types defined in cpl_port.h (G[U]Int[8/16/32/64/Big]) by their standard [u]int[8/16/32/64]_t C99/C++11 counterparts, as well as other derived integer data types. Due to the API and ABI break, this will be implemented in GDAL 4.0.
The existing Gxxxxx typedefs have been defined at a time that predates C99 and C++11 which introduced those fixed with integer types. If GDAL would be created today, we would use C99 data types.
Using those aliases, particularly GIntBig/GUIntBig which are not self-explanatory on their actual width (64 bit), adds cognitive load to developers.
Due to their poor namespacing, those short typenames may occasionally clash with other libraries. At a time, Poppler used a
GBooldata type as well, which was clashing with GDAL's one.
Other projects (e.g. libtiff), have recently switched from the use of similar custom types to C99 ones.
The following data types replacement are done in the whole code base:
GBoolwas aliased to
Other changes have been done for other integer data types:
int64_t(affects mostly C++ raster drivers)
ptrdiff_t(affects the multidimensional C and C++ API)
The following macro replacement are done in the whole code base:
The old types are no longer used in the GDAL code base since
their definition is protected by
#ifdef GDAL_USE_OLD_INT_TYPES, which
external code might define to help for the migration (particularly if supporting
GDAL < 4.0 and GDAL >= 4.0 is needed)
Impacts in the code base
Significant part of the code base (735 files changed). Most changes have been done in a automated way, with manual changes specifically for the CPL_FRMT_GIB/CPL_FRMT_GUIB replacement which was harder to automate.
While .i files are impacted to cope with the C type changes, the language specific API of SWIG bindings is not impacted.
C and C++ API and ABI are impacted.
Main impacts are:
GBool was aliased to
int: changing to
boolin C++ methods of the OGRStyleXXXX classes affect the API and ABI. Impact should be modest as this functionality is thought to be marginally used, and this only impacts the C++ API (the C API for those methods uses
GIntBig/GInt64 was aliased to
long longand GUIntBig/GUInt64 to
`unsigned long long. While
long longhave in practice same width and signedness, they are formally different data types. For scalar usage of those types, compilers shouldn't warn. But for usage of those types as pointers, compilers warn in C (
-Wincompatible-pointer-typeswith gcc) and error outs in C++ (unless
-fpermissiveis passed), when mixing a
int64_tpointer and a
long longpointer (similarly for their unsigned counterparts).
C Raster API impacts (and equivalent C++ methods):
GDALGetDefaultHistogramEx()(e.g. used by QGIS)
GDALGetRasterHistogramEx()(e.g. used by QGIS)
C Vector API impacts (and equivalent C++ methods):
C Multidimension API impacts (and equivalent C++ methods):
Out-of-tree drivers are also impacted:
The changes of this RFC are somewhat risky, particularly the replacement of the
formatting macros CPL_FRMT_GIB/CPL_FRMT_GUIB with the PRId64/PRIu64 ones, which
requires to add a
% formatting character. While compilers caught most of the
mismatches, there were remaining ones undetected at compilation time. Manual
corrections have been done to make the regression test suite pass.
Additional "grep"-based searches in the code base have been done to find faulty
patterns, but we cannot exclude that some might have been missed.
MIGRATION_GUIDE.TXT will be updated to point to this RFC.
No changes in Python tests. Updates in the C++ test suite.`