Proposing to call setlocale( LC_ALL, "C" ) in msSetup()

[Umberto Nicoletti]

On 4/28/06, Frank Warmerdam <warmerdam at pobox.com> wrote:
> Umberto Nicoletti wrote:
> > Hi,
> > I think the solution is worse than the problem. While it should pose
> > no problem for mapserver cgi I can easily imagine it wreaking the
> > havoc in Java mapscript and even C# mapscript.
>
> Umberto,
>
> Can you explain what sort of havoc this may wreak on Java mapscript?
>

Hi Frank.

First is thread safety: I have read somewhere but I have lost the link
that atof is thread safe unless setlocale is called while executing.
This could happen if we call setlocale from within gdal and reset it
afterwards.

Second the Java VM respects the LANG and LC_* variables so changing
the locale internally and   for small execution intervals will almost
certainly cause incosistent behaviour at different times in the jvm: a
number could be parsed in the C locale at one time and in the it_IT
another. Even worse this could affect the whole tomcat process which
could be running many other apps too.

> I can certainly forsee problems if mapscript is loaded into apache,
> in that our setlocale() action may affect all other activity using
> the c runtime in Apache.  Is that the sort of issue you are concerned
> about?

Exactly.

>
> > I am for rewriting the code to be locale sensitive and if possible
> > will try to help, but cannot make promises as I am on a really tight
> > schedule to fix another localization bug with Java mapscript
> > (http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1753).
>
> Well, none of us can make binding promises, but without a clear
> indication of the issues and options you see, I would end up falling
> back on my own experience within GDAL.
>

I hope I made myself clear.

Of course those issues are probaly related to other mapscript too.

Best regards,
Umberto

> There we have pursued a two part strategy.
>
> 1) Temporarily push the C numeric locale when within GDAL.  However calling
> setlocale() is relatively expensive, so we can't afford to do it all the time.
> So instead we do it in key calls (like GDALOpen()) and leave it to the
> application code to enforce it more generally if needed.
>
> 2) We are working on writing locale-free versions of functions like atof(),
> and sprintf() that we can try to use widely to give "C locale" parsing and
> formatting regardless of the locale set for the purposes of the user.  This
> has proven to be fraught with peril before have even gotten to the point of
> trying to use these functions!
>
> 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
>
>