On 08/13/12 14:37, Adriano dos Santos Fernandes wrote:
> On 13/08/2012 04:29, Alex Peshkoff wrote:
>>  On 08/10/12 21:13, Dimitry Sibiryakov wrote:
>>> 10.08.2012 19:10, Adriano dos Santos Fernandes wrote:
>>>> Then bug will remains in embedded engine usage. It's not a good option
>>>> to let applications (ISQL or user ones) to deal with things that must
>>>> works automatically.
>>>    Using locale information or ignoring it is up to application developer. 
>>> Library must 
>>> not ignore his will.
>> Yes. I think setlocale() call should be done in all our executables, but
>> not in library.
>>
>> The only possible addition - if setlocale() was not called, probably out
>> library also should not perform any conversions, just send strings 'as is'?
>>
>>
> This seems completely wrong solution. Our caller may not even have easy
> access to setlocale (of the same CRT as ours).
>

Taking into an account that posix build is used not only on linux (have
you ever seen linux with >1 CRT?) I can agree with this argument.

> Also there may be interdependent library which one needs it, and another
> could not work well with it.
>
> If this is not a bug or some problem in our usage, that seems to be the
> wrong library call we're doing, our the design of intl things in Linux
> is very broken.

Appears that according to man we really MUST initialize locales using
setlocale(). What we see in man:

> On startup of the main program, the portable "C" locale is selected as
> default.  A program may be made portable to all locales by calling:
>            setlocale(LC_ALL, "");

I.e. we really need to do that init in main library (yValve, not engine)
in order to make posix locales work.



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to