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
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
