On Sat, 28 Sep 2024, Pali Rohár wrote:
Add symbols __initialize_lconv_for_unsigned_char, _query_app_type and _set_app_type into msvcrt import libs. --- mingw-w64-crt/def-include/crt-aliases.def.in | 13 +++++++++++++ mingw-w64-crt/lib32/crtdll.def.in | 2 ++ mingw-w64-crt/lib32/msvcr80.def.in | 1 + mingw-w64-crt/lib32/msvcr80d.def.in | 1 + mingw-w64-crt/lib32/msvcr90.def.in | 1 + mingw-w64-crt/lib32/msvcr90d.def.in | 1 + mingw-w64-crt/lib32/msvcrt10.def.in | 2 ++ mingw-w64-crt/lib32/msvcrt20.def.in | 1 + mingw-w64-crt/lib64/msvcr90.def.in | 1 + mingw-w64-crt/lib64/msvcr90d.def.in | 1 + mingw-w64-crt/misc/__set_app_type.c | 3 +++ 11 files changed, 27 insertions(+)
Same comment as for patch 1/2 - I guess the implementation is acceptable, but I don't see the full need for it.
Are you planning on refactoring some of the crt startup files to unify things around the UCRT function interfaces? Or is it just for consistency across the internal symbols that normally isn't referenced externally?
In this case also, we already have UCRT providing __lconv_init as an alias for __initialize_lconv_for_unsigned_char - so __lconv_init is the canonical symbol name we're using in our object files. Are we going to switch things to use __initialize_lconv_for_unsigned_char and remove the alias in UCRT?
Because I find it useful to align on one name internally, and then make sure that all CRT libraries provides that symbol in some form. But making sure that all CRT libraries provides both old and new interfaces for everything feels like it just adds more work for us for less value.
// Martin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
