Re: locale, gui vs command line question?

["Freddie Unpenstein" <fredderic excite com>]

> On Sun, 31 Jan 2010, james morris wrote:
> > Generally, changing locale locally is fragile and better avoided.
> >
> > I've tried the above out by storing the current locale setting, changing
> > it to "C" and then restoring the locale setting once read/write is
> > finished and it seems to work (I installed a locale using commas as
> > decimal point).
> >
> > But I was told not to do this (on stackoverflow), but without the reason
> > why - and to use ieee754.h (which is no good considering I'm mainly
> > using MPFR).
> >
> > Why is store/change/restore of locale bad?

> There's nothing at all wrong with it in the context you specified
> -- i.e. you want to ensure that floating-point values written to
> and read from file always use '.' as the decimal separator. I do
> that in my app, gretl (also for reasons of portability).

The problem would be the potential that the library may have cached locale features under a different locale, 
wouldn't it?  That could lead to either uninitialised bytes, or buffer overrun.

> From personal experience; I've first-use-allocated strings with all the thousands characters, and an array 
> of byte offsets at which to put the higher portions of numbers, and then used a regular floating point 
> format to write the last thousand (sprintf comes to mind).  If the locale were to unexpectedly change to one 
> that uses a multi-byte decimal point, a buffer overrun would certainly occur.  In the opposing case, that 
> same function would likely write out a null character following the number.

Could cause quite some stress.


Fredderic

------------------------------------------------------------
Best Weight Loss Program - Click Here!
Weight Loss Program
http://tagline.excite.com/c?cp=vXYG-fGF-EFlsgtFzMFtVgAAKZSqLQhMVy_O-FcGiDoF0G0BAAYAAAAAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAAAAEUkgwwww=