-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consolidate UTF8 character encoding implementations #78490
Comments
Tagging subscribers to this area: @dotnet/area-meta Issue DetailsWe have two character encoding implementations for Utf8 <-> Utf16 <-> UCS4 in runtime; located at:
The coreclr/pal implementation was ported from C# implementation in 2016: dotnet/coreclr#3809. The C# implementation has diverged / improved since with spanified and intrinsified APIs so much that the similarities between the two are unrecognizable. We can move eglib/giconv.c from mono to src/native/minipal, and create a neutral C header, so both coreclr pal and mono glib can rely on a unified APIs. There are also some unused methods in these files (e.g.
|
Sounds good to me. Make sure that the shared implementation is at least as fast as the current one.
We should not need that. |
Tagging subscribers to this area: @dotnet/area-system-text-encodings-web Issue DetailsWe have two character encoding implementations for Utf8 <-> Utf16 <-> UCS4 in runtime; located at:
The coreclr/pal implementation was ported from C# implementation in 2016: dotnet/coreclr#3809. The C# implementation has diverged / improved since with spanified and intrinsified APIs so much that the similarities between the two are unrecognizable. We can move eglib/giconv.c from mono to src/native/minipal, and create a neutral C header, so both coreclr pal and mono glib can rely on unified APIs. There are also some unused methods in these files (e.g.
|
@jeffhandley, it is not related to System.Text.Encodings.Web. This is about consolidating native implementations of encoding used internally by coreclr and mono. Managed libraries don't consume these implementations. |
Tagging subscribers to this area: @dotnet/area-meta Issue DetailsWe have two character encoding implementations for Utf8 <-> Utf16 <-> UCS4 in runtime; located at:
The coreclr/pal implementation was ported from C# implementation in 2016: dotnet/coreclr#3809. The C# implementation has diverged / improved since with spanified and intrinsified APIs so much that the similarities between the two are unrecognizable. We can move eglib/giconv.c from mono to src/native/minipal, and create a neutral C header, so both coreclr pal and mono glib can rely on unified APIs. There are also some unused methods in these files (e.g.
|
Ah; thanks, @am11. |
We have two character encoding implementations for Utf8 <-> Utf16 <-> UCS4 in runtime; located at:
src/coreclr/pal/src/locale/{utf8,unicode}.cpp
src/mono/mono/eglib/giconv.c
The coreclr/pal implementation was ported from C# implementation in 2016: dotnet/coreclr#3809. The C# implementation has diverged / improved since with spanified and intrinsified APIs so much that the similarities between the two are unrecognizable.
We can move eglib/giconv.c from mono to src/native/minipal, and create a neutral C header, so both coreclr pal and mono glib can rely on unified APIs. There are also some unused methods in these files (e.g.
g_utf8_to_ucs4_fast
) which can be cleaned up at the same time.The text was updated successfully, but these errors were encountered: