On Fri, 11 Oct 2024, Pali Rohár wrote:
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.
Yes, if we unify things, I would prefer unifying on the UCRT interface.
And for that, I guess patch 2/2 is a start - but I would like to see the
end of that refactoring at the same time before merging it (i.e. dropping
the __lconv_init aliases in UCRT), to get a feel of the overall benefit of
the patchset.
The interfaces that are mentioned here are somewhat public at least, so I
guess it can be reasonable to do UCRT unification of that - but if they
would be entirely internal, I would be slightly more sceptical to whether
the refactoring is worthwhile at all.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
