[gdal-dev] Global pass to fix issues related to floating point <--> string conversions sensitive to locale / LC_NUMERIC

Even Rouault even.rouault at spatialys.com
Tue Nov 11 09:37:02 PST 2014


Hi,

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 
QGIS.

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 
functions.
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).

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list