On Tuesday 06 May 2025 17:38:40 Martin Storsjö wrote:
> On Tue, 6 May 2025, Martin Storsjö wrote:
>
> > On Thu, 17 Apr 2025, Pali Rohár wrote:
> >
> > > There is missing call _configthreadlocale(-1) in pre_c_init function.
> > > Startup code from Visual C++ runtime is doing same thing.
> > >
> > > This applies only for msvcr80+ and UCRT builds. For older msvcrt versions
> > > there is only empty wrapper.
> > > ---
> > > mingw-w64-crt/crt/crtexe.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
> > > index 4bc8a92f497a..6da7e23fba92 100644
> > > --- a/mingw-w64-crt/crt/crtexe.c
> > > +++ b/mingw-w64-crt/crt/crtexe.c
> > > @@ -112,6 +112,7 @@ pre_c_init (void)
> > >
> > > if (__globallocalestatus == -1)
> > > {
> > > + _configthreadlocale(-1);
> >
> > What is the parameter -1 here?
> >
> > According to the docs, we can pass _ENABLE_PER_THREAD_LOCALE (1) or
> > _DISABLE_PER_THREAD_LOCALE (2), or 0 to query the current setting. But
> > the docs don't say anything about passing -1 as parameter.
>
> Also secondly; does this ever get called here?
>
> This only gets called if we have __globallocalestatus == -1, but
> __globallocalestatus is initialized to ~0x1 (== -2) in crt/xthdloc.c. I
> don't see any code changing it, other than if user could would do it (the
> variable is declared in ctype.h and mbctype.h, but it seems very much
> internal/undocumented). Is this something where MSVC has a better
> user-facing way of configuring it, while our CRT has some remnants of
> something similar, but which is essentially impossible to use in its current
> form?
>
> // Martin
msvc has more object configuration files which are supposed to be passed
to linker, and they change behavior of the startup code. Documentation:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/link-options
In works in a way that every object file just initialize variable to
some specific value. And all those variables are used by the startup
code which is always linked.
There are some "fallback" object files which are linked when symbols are
not explicitly defined by specifying one of those above object
configuration file, or by the application itself.
For this __globallocalestatus variable. There is a threadlocale.obj file
which sets the __globallocalestatus to -1 and hence activates the
per-thread locale by default for all new spawned thread.
In mingw-w64 we do not have an object file threadlocale.o and neither
import library which could do similar thing. But applications are free
to define that variable by their own and so enable per-thread locales
globally.
I agree that __globallocalestatus variable is somehow undocumented but
it is available in header files as a public one.
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
