Re: btowc problem

Eli Zaretskii <eliz-mXXj517/[email protected]> Tue, 30 Jun 2020 20:47:47 +0300
Newsgroups gmane.comp.gnu.mingw.user
Message-ID <[email protected]>
> Date: Tue, 30 Jun 2020 18:44:32 +0300
> From: Eli Zaretskii <[email protected]>
> 
> > Date: Tue, 30 Jun 2020 18:09:08 +0300
> > From: Eli Zaretskii <[email protected]>
> > 
> > So basically, I think that we must provide in libmingwex the wchar.h
> > functions that might not be available in MSVCRT.DLL, so that programs
> > could reliably work on XP and older systems.
> 
> I'm no longer sure this conclusion is correct.

Or maybe I do.

This factoid seems to be relevant: previously I used MinGW runtime
5.2.1, where libmingwex had both btowc and mbrtowc.  But in MinGW
runtime 5.3.1, which is what I have now, libmingwex doesn't have those
functions, and instead has __msvcrt_btowc and __msvcrt_mbrtowc.  So if
a program is linked with a library that includes btowc and mbrtowc as
unresolved externals, the linker would find it in libmingwex 5.2.1,
but not in libmingwex 5.3.1.  The result, predictably, is that in GDB
9.1, which was compiled with mingwrt-5.2.1, I see the code of btowc
from libmingwex, whereas in GDB 10 compiled with mingwrt-5.3.1 I see
an indirect call to MSVCRT's btowc instead.

Does this sound like the correct explanation for what I'm
experiencing?

_______________________________________________
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