[Insight-developers] [vtkusers] wx/vtk weirdness

[Tom Vercauteren]

Hi Bill,

I would just like to mention that in our group we have been facing
several issues with locale support on mac.

Looking at the documentation of xlocale:
  http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html
you will see that setlocale will have absolutely no effect (on mac,
maybe on windows also
http://msdn.microsoft.com/en-us/library/26c0tb7x.aspx ) if a
per-thread locale had been specified.

Using newlocale, duplocale, uselocale and freelocale seems a better option:
  http://www.opengroup.org/onlinepubs/9699919799/functions/uselocale.html
  http://www.opengroup.org/onlinepubs/9699919799/functions/newlocale.html
  http://www.opengroup.org/onlinepubs/9699919799/functions/duplocale.html
  http://www.opengroup.org/onlinepubs/9699919799/functions/freelocale.html


For example, to put only the LC_NUMERIC parameter to C, here is how we
chose to proceed:

// Create a new locale based on a copy of the current one (which need
not be explicitly set)
// but where LC_NUMERIC has been modified to match the C locale
locale_t tempLocale = newlocale(LC_NUMERIC_MASK, NULL, NULL);
// Use this new locale and store the current one to reset it aftwards
locale_t previousLocale = uselocale(templocale);

[Actual useful code]

// Reset the locale to the previous one
uselocale(previousLocale)
// More house keeing
freelocale(tempLocale)


Actually, on mac we also had to do explicitly create thread-specific
locale to avoid some random crash in heavily threaded code. But that
is a slightly different topic

Cheers,
Tom


On Mon, Nov 30, 2009 at 17:08, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> I've already made a pass through the itk readers. Several were broken
> wrt locale.
>
> I used a combination of C++ and C locale api's. I encapsulated the C
> locale in and itk::Locale class.
>
> I have not checked in any changes yet, but I went from over 40 failing
> I/O tests down to 0.
>
> Bill
>
> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>> Luis,
>>>
>>> Actually, we can surround certain functions with c-style setlocale and
>>> it solves the problems. I already fixed StimulateImageIO,
>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>> any changes yet. Still more investigation is needed as to the best
>>> portable solution.
>>>
>>> I do this:
>>>   const char *originalLocale;
>>>   char *currentLocale;
>>>   originalLocale = setlocale(LC_NUMERIC, NULL);
>>>   currentLocale = strdup(originalLocale ? originalLocale : "C");
>>>   setlocale(LC_NUMERIC, "C");
>>>
>>> ......
>>>
>>>
>>> setlocale(LC_NUMERIC, currentLocale);
>>>         free(currentLocale);
>>
>> A page from the Apache C++ resource site gives some good explanations of why
>> the C++ locale should be preferred. Mainly because the C locale is a global
>> resource, whereas in the C++ locale instances of the locale can be created.
>>
>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>
>>> For example in StimulateImageIO I surrounded the calls in
>>> StimulateImageIO::InternalReadImageInformation with the above
>>> snippets.
>>>
>>> There are other readers/writers that use C++ streams, and there we
>>> will have to imbue.
>>
>> I think that using the C locale is probably the easiest short term solution,
>> but to support GUIs using different locales we should be using the C++ locale
>> class and associated API. Otherwise users of our libraries may suffer from
>> subtle bugs if reading and writing files in separate threads that are all
>> using C locales.
>>>
>>> Even in some code that uses streams, people still use sscanf, atof,
>>> etc. In the long run we probably should address these cases with
>>> stream replacements.
>>
>> We should aim to ensure new code uses C++ streams and imbue, and replace
>> existing code with C++ streams. As you say this should probably be part of a
>> larger i18n effort which would involve using Unicode strings and other changes
>> to our libraries.
>>
>> Marcus
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>