Re: btowc problem

Keith Marshall <[email protected]> Wed, 1 Jul 2020 22:14:54 +0100
Newsgroups	gmane.comp.gnu.mingw.user
Organization	MinGW.org Project
Message-ID	<[email protected]>
On 01/07/2020 16:08, Eli Zaretskii wrote:
> From: Keith Marshall <[email protected]>
> Date: Tue, 30 Jun 2020 21:33:14 +0100
>> And ... in writing this, I think I've walked into the real explanation,
>> which in turn leads to the solution: we need to rebuild libmsvcrt.a,
>> omitting the offending symbols -- i.e. all of those which we want to be
>> accessed exclusively via __msvcrt_redirect references in libmingwex.a.
> 
> I'm probably missing something, but how can this work if one links a
> program compiled under mingwrt-5.3.x, but with some libraries compiled
> by older mingwrt?

It can't; but that's the point ... we don't want it to.  Like it or not,
mixing libraries across versions is asking for trouble.

> Those older libraries will want to resolve btowc and the other
> wchar.h functions which were previously in libmingwex. If you want
> libmsvcrt.a to solve this, you will have to put in there btowc etc.
> that call back into libmingwex.a's __msvcrt_* versions, no? And that
> would make libmsvcrt.a not really an import library anymore, although
> maybe we don't care?>
> My suggestion was to add to 5.3.x libmingwex.a implementations of
> btowc etc. that simply call the corresponding __msvcrt_* functions, so
> that libraries compiled by older MinGW versions could still be happy
> when linked under the newer mingwrt.

No, that cannot work; it would create a recursive call loop with no
terminal condition, until the process runs out of stack space.  If we
must maintain cross-version compatibility, then we must accept that all
of the MSVCRT.DLL -- and MSVCRn.DLL -- implementations of btowc, mbrlen,
mbrtowc, mbsrtowcs, wctob, wcrtomb, and wcsrtombs are unfit for purpose,
(which I suspect to be the case anyway[*]), and not attempt to use them
under any circumstances, and just use the libmingwex.a implementations
exclusively.

[*] I had my doubts about delegating to MSVCRT.DLL implementations of
any of these functions, because Microsoft's choice of UTF-16LE as the
underlying representation of wchar_t precludes any one-to-one mapping of
any possible Unicode code point to a single wchar_t, (as is required for
ISC-C99 conformance), and Microsoft's online documentation conveniently
neglects to mention the limitation.  This discussion is convincing me
that my doubt was vindicated, and we should revert to use of our MinGW
implementations exclusively, (but using the new implementations, because
they did address some failings of their predecessors); thus, functions
in this group, in mingwrt-5.3.x, named __msvcrt_foo() and corresponding
__mingw_foo() would disappear, to be consolidated into foo().

-- 
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)