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 -------------- next part -------------- A non-text attachment was scrubbed... Name: libmingwex-update.tar.xz Type: application/x-xz Size: 86324 bytes Desc: not available URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20200704/956ba029/attachment-0001.xz> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20200704/956ba029/attachment-0001.sig>
Fork