Re: btowc problem

Keith Marshall <[email protected]> Fri, 3 Jul 2020 14:54:02 +0100
Newsgroups	gmane.comp.gnu.mingw.user
Organization	MinGW.org Project
Message-ID	<[email protected]>
On 03/07/2020 13:51, Eli Zaretskii wrote:
>> You are saying that __msvcrt_* functions call btowc etc.?  I thought
>> they were doing that via a function pointer, which gets populated at
>> run time?
> 
> I think I see what you were alluding to.  It's this code in the
> __msvcrt_* functions:
> 
>   if(  (redirector_hook == NULL)
>   &&  ((redirector_hook = dlsym( RTLD_DEFAULT, "btowc" )) == NULL)  )
>   {
>     /* ...but when no Microsoft implementation can be found, register
>      * the MinGW fallback in its stead.
>      */
>     redirector_hook = __mingw_btowc_fallback;
>   }
> 
> Since the dlsym call uses RTLD_DEFAULT, it will search the modules
> that are already loaded into the program's address space, and will
> thus find the implementation I proposed to put in libmingwex, which
> then will cause it to call itself, recursively, this blowing up the
> stack.  Not good.

Yes, this precisely identifies the problem.

> But we could instead look for these functions explicitly in
> MSVCRT.DLL, not in all of the loaded modules, couldn't we?

But that presupposes that the application is linked with MSVCRT.DLL; it
will fail, if the user links with any of MSVC's non-free MSVCRn.DLLs,
(which we do endeavour to support).  Dealing with that is a complexity
with which I would prefer not to contend.

> However, if this is not a good idea, then yes, I think having these
> functions in libmingwex that redirect to __mingw_* replacements
> unconditionally is a good-enough solution.

This would be my preference ... indeed, it always has been, but the
question arose: why not use the MSVCRx.DLL implementations?  I never
really wanted to do so, but when I invited opinion, no one offered any.
Maybe I just needed to break it, to raise the profile.

What I propose, for mingwrt-5.4, is to rename __mingw_btowc, et al, back
to their original ISO-C99 names, in libmingwex.a.  Of course, this will
cut off access to the MSVCRx.DLL variants, but I'm not too bothered by
that, since a) it was always thus, prior to mingwrt-5.3.x, and b) I
strongly suspect that the Microsoft implementations are unfit for
purpose, anyway.  I would then like to delete the __mingw_btowc et al,
and __msvcrt_btowc et al redirectors, (since they will no longer be
useful); however, if you think it may be prudent to keep them as simple
aliases for the ISO-C99 names, in the interim, I can do so for 5.4, but
I would really like them to be gone, by the time we get to mingwrt-5.5.

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

_______________________________________________
MinGW-Users mailing list
[email protected]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.osdn.me/mailman/listinfo/mingw-users
Also: mailto:[email protected]?subject=unsubscribe
signature.asc (application/pgp-signature, 833 B)