On Thursday 10 October 2024 20:45:11 Martin Storsjö wrote: > On Thu, 10 Oct 2024, Pali Rohár wrote: > > > On Thursday 10 October 2024 15:14:22 Martin Storsjö wrote: > > > 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 > > > > UCRT names are available in public header file corecrt_startup.h so > > those functions can be used easily by applications. So I think that > > providing "standard" available functions into all CRT libraries makes > > sense. Also we already have some of them (like __lconv_init). > > > > Symbol aligning to the new/ucrt names is a good idea which can be done > > later then. > > > > And for compatibility reasons I think that it is a good idea to provide > > by ucrt import library also symbols which are in the msvcrt library. > > I disagree with this direction. > > We should unify the object file level interface across CRTs, yes. > > For things that are originally UCRT specific, but visible in public headers > - maybe. > > But providing old msvcrt era symbols in UCRT import library? If it is needed > due to some internal use in mingw-w64-crt? Sure. If it's needed to solve > some other, real user problem? Sure. But just in case, because a user could > declare the function themselves? No, that's where I draw the line. > > If we include compatibility with "the user could declare things themselves" > in our compatibility mission, what we need to support grows quite > significantly, for an entirely hypothetical case. And I would say we have > quite enough to maintain while focusing on the non-hypothetical cases. > > // Martin
That is a good point. Anyway, for unification of object level interfaces across all CRTs there two sane options: 1) unify all names to UCRT naming 2) unify all names to msvcrt naming If we choose the first option then then the PATCH 2/2 is a good starting point. PATCH 1/2 can be dropped. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
