Error parsing mapfile with floats us

[Frank Warmerdam]

Szekeres Tamás wrote:
> Frank, Howard,
> 
> Yes it was a local specific issue, I have added some
> additional prints to the program:
> 
> current locale (LC_NUMERIC)=  hu_HU.UTF-8
> locale.decimal_point=,
> atof(51.447)=51,000000  atof(51,447)=51,447000
> 
> So the question is: if the parser expects dots as the
> decimal separator for floats it should set the default
> locale previously or use locale independent conversion, like
> atof_l.  :?

Tamas,

I don't think atof_l() is portable.  In any event there are many
places in mapserver (all the XML parsing!) that could have problems.
And many sub-libraries such as GDAL/OGR have similar issues.  I think
we should just declare that MapServer must run in the C numeric locale
and enforce it by calling 'setlocale( LC_NUMERIC, "C" );' in msSetup().

On the plus side it ensures a C locale for MapServer and all supporting
libraries.  On the downside it defeats use of the locale for any formatted
output from MapServer such as query results.  A more important issue is that
if MapServer capabilities are being used from within the Apache process
(such as with dso loaded PHP or other mapscripts) the setlocale() call is
going to affect all other operations in the same process.

But in the long term I think it is just a nightmare to support big
applications in non-"C" numeric locales.

Assuming we do put the setlocale() in msSetup() it will also be necessary
to ensure msSetup() actually gets called in the various environments in
a timely fashion.

I would suggest you put a setlocale() in msSetup() proposal (not a full RFC,
just a well named email) to the TSC for a vote.   Some folks may miss this
discussion buried in this thread.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org