Re: btowc problem

Keith Marshall <[email protected]> Sat, 4 Jul 2020 13:51:56 +0100
Newsgroups	gmane.comp.gnu.mingw.user
Organization	MinGW.org Project
Message-ID	<[email protected]>
On 03/07/2020 16:01, Eli Zaretskii wrote:
>>> 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.
> 
> I'm sorry I didn't voice my opinion back then.  Perhaps I just didn't
> have one, or didn't understand the implications.

Perhaps I didn't emphasize the possible implications sufficiently;
indeed, although I did expect them, perhaps even I didn't appreciate the
likely extent of their impact.

>> 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.
> 
> The only reason I can think of to keep the __msvcrt_* and __mingw_*
> redirectors is to allow people who have libraries compiled with
> mingwrt-5.3.x to link against them without recompiling.  I'm generally
> biased towards backward compatibility, but since you are doing the
> work, it's your call.  If mingwrt-5.4 is going to be released soon,
> perhaps the window during which 5.3.x will have been used could be
> considered small enough to not present a significant problem.

The coding is done, and the man pages are updated.  I still need to
consolidate my patch queue, and update the ChangeLog before publishing;
in the meantime, I've attached an updated (stripped) libmingwex.a, and
accompanying modified wchar.h ... unpack the tarball in your $MINGW_ROOT
to overwrite the existing copies.

Note that the __mingw_*, and the __msvcrt_* references are gone from the
modified wchar.h, but remain as weak aliases in libmingwex.a.  I plan to
publish, in this form, as mingwrt-5.3.4, then immediately remove those
aliases, and republish as mingwrt-5.4.

-- 
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
libmingwex-update.tar.xz (application/x-xz, 84.3 KB) - not displayed
signature.asc (application/pgp-signature, 833 B)