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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
