[Gdal-dev] locale handling in GDAL

Ben Discoe ben at vterrain.org
Sat Mar 4 04:40:37 EST 2006


> -----Original Message-----
> From: Frank Warmerdam
> 
> Peng Gao has pointed out that GDAL can fall over rather 
> ungracefully if used in a locale with odd numeric formatting 
> rules, such as many European locales.
> 
> For instance, in the Danish locale printf( "%g\n", 1.234) 
> will produce "1,234"

Indeed; in fact, the issue is not just internal to GDAL, but also in user
code built on it, which e.g. might call atof on a field value returned by
OGR.  So developers should be aware that they need to consider it this
themselves, not just expect a library to take care of it for them.

OGRSpatialReference is especially sensitive.  Nearly every method will fail
badly with Euro locale, as they atof/ftoa heavily.

> [...] I implemented this using a small 
> class declared in cpl_conv.h called CPLLocaleC.  When 
> created, objects of this class will force LC_NUMERIC to C.  
> When destroyed they will restore the
> original locale setting.

Interesting, i did the same thing years ago (VTP's is called LocaleWrap) and
declare it in each scope which calls GDAL/OGR, as needed.

> I have introduced it's use into GDALOpen, GDALCreate, 
> GDALCreateCopy and GDALClose.  *Most* parsing and formatting 
> for disk access takes place in these functions

If you want to get serious about this, OGRSpatialReference would be the next
place to look.  Otherwise, you could just expose and document CPLLocaleC so
that developers can take on the responsibility themselves.  That way they
can minimize the overhead.

> BTW, I have also introduced a --locale commandlnie option in 
> the GDAL standard command line option process

Interesting, i did the same thing a while back with a -locale=xx command
line option :)

-Ben




More information about the Gdal-dev mailing list