[gdal-dev] Global pass to fix issues related to floating point <--> string conversions sensitive to locale / LC_NUMERIC
even.rouault at spatialys.com
Tue Nov 11 09:37:02 PST 2014
Just to notify you that with http://trac.osgeo.org/gdal/ticket/5731 I've done
a global pass on the whole source tree to hopefully address most issues
related to floating-point <--> string conversions that were sensitive in a lot
of places to the LC_NUMERIC setting, when it was comma instead of point. Which
could cause issues when GDAL is integrated into locale-enabled programs like
There are now variants of standards functions of the printf() family,
CPLsprintf(), CPLsnprintf(), CPLvsnprintf(), that will output decimal point
whatever the current locale is.
The already existing similar functions like CPLSPrintf(),
CPLString::Printf(),vPrintf(), etc... now use those new locale-insensitive
There's also a CPLsscanf(), which is currently limited to formatting strings
with "%lf" in them.
So use of the CPL variants is strongly encouraged when dealing with floating
point numbers in drivers.
Consequently, I've been able to remove most uses of CPLLocaleC in the source
tree, which is something that cause issues in multi-threaded context,
particularly on Windows. The remaining ones are in the interface with proj.4
(recent proj.4 versions change LC_NUMERIC to C if necessary, but without the
locking that seems to be needed with recent MSVC, so if we do it from GDAL
hopefully it should improve things) and the LIBKML driver. The most criticals
uses of CPLLocaleC were the ones that have been removed in the Open(),
Create(), CreateCopy(), Identify() methods of the generic driver code. It
might be necessary to reintroduce it in the few drivers that would need them.
I won't pretend this solves all issues, but hopefully it should solve most.
Now the autotest suite passes with non-English locale set. Note that this is
not an absolute guarantee that we consistently write decimal points, since
outputting floating point numbers with comma and reading them back works OK,
and will remain undetected, unless tests really check file contents at low-
level. Issues with shapefiles, mapinfo, etc for example were undetected (but
are now fixed).
Spatialys - Geospatial professional services
More information about the gdal-dev