Tcl - l10n startup (WAS: Re: ANNOUNCE: Tcl Plugin v3.1)

Author

l10n startup (WAS: Re: ANNOUNCE: Tcl Plugin v3.1)

Jeff Hobbs

2006-06-24, 8:23 am

Donal K. Fellows wrote:
> Andreas Leitgeb wrote:
>
> As I understand it, the problem is a combination of the way Windows does
> certain functionality (by loading DLLs instead of talking to services)
> and the fact that some DLLs like to diddle with reinitialising the
> locale (a big no-no). Unix overall tends to not do that (for whatever
> reason) and so these problems, which still theoretically exist, don't
> bite for real.

In addition, the browser plugin and similar applications are the most
susceptible because they operate as sub-libraries and not the primary
application at all times.

Hmmm, in fact, this may be more the location of the problem. For unix,
we do the setlocale in tclUnixInit.c:TclpSetInitialEncodings. On
Windows, it instead occurs in tclAppInit.c:main. That means only tclsh
does the setlocale on Windows, whereas any library usage should call it
on unix. Has anyone noticed if this problem crops up on unix systems as
well?

Jeff

MartinLemburg@UGS

2006-06-24, 8:23 am

Jeff Hobbs wrote:
> Donal K. Fellows wrote:
>
> In addition, the browser plugin and similar applications are the most
> susceptible because they operate as sub-libraries and not the primary
> application at all times.
>
> Hmmm, in fact, this may be more the location of the problem. For unix,
> we do the setlocale in tclUnixInit.c:TclpSetInitialEncodings. On
> Windows, it instead occurs in tclAppInit.c:main. That means only tclsh
> does the setlocale on Windows, whereas any library usage should call it
> on unix. Has anyone noticed if this problem crops up on unix systems as
> well?
>
> Jeff

Hi Jeff,

the problem is not located during the l10n startup, not on MS Windows!

We had this problem while our Application was running, because a user
used a file selection box to walk through the complete system causing
MS Services for Unix (NFS) DLLs to be loaded, which changed the locale
of our applicaton (yes ...a no-no, but they did!).

To guarantee a non-problematic l10n startup even in libraries would be
a nice, but a locale independent number parser using compat/strtod.c
would be much finer.

Best regards,

Martin Lemburg
UGS - Transforming the Process of Innovation

Don Porter

2006-06-24, 8:23 am

Jeff Hobbs wrote:
> Hmmm, in fact, this may be more the location of the problem. For unix,
> we do the setlocale in tclUnixInit.c:TclpSetInitialEncodings. On
> Windows, it instead occurs in tclAppInit.c:main. That means only tclsh
> does the setlocale on Windows, whereas any library usage should call it
> on unix.

To try to say that a different way, Tcl's call to

setlocale(LC_NUMERIC, "C");

on unix is in TclpSetInitialEncodings, which gets called (eventually)
by Tcl public routine Tcl_FindExecutable(). Any program that embeds
Tcl and calls Tcl_FindExecutable() (all embedding programs should!)
gives Tcl a chance to establish its locale needs on Unix.

By contrast, on Windows, Tcl's call to

setlocale(LC_ALL, "C");

is found only in the main() routine of tclsh, so other programs
that embed Tcl never actually call it on Windows, unless they arrange
for their own call to setlocale(), which is what wish does.

Looking at the plugin sources, I see that they do call Tcl_FindExecutable,
but they do not include a direct call to setlocale().

--
| Don Porter Mathematical and Computational Sciences Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|_______________________________________
_______________________________|

Ralf Fassel

2006-06-24, 8:23 am

* Don Porter <dgp@email.nist.gov>
| Looking at the plugin sources, I see that they do call
| Tcl_FindExecutable, but they do not include a direct call to
| setlocale().

Even if they did call setlocale() at their startup it would not
matter, since that would only fix things until the next DLL is loaded
which changes the locale again.

R'

Sponsored Links