Skip to content
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

Closed
am11 opened this issue Nov 17, 2022 · 7 comments · Fixed by #85558
Closed

Consolidate UTF8 character encoding implementations #78490

am11 opened this issue Nov 17, 2022 · 7 comments · Fixed by #85558
Milestone

Comments

@am11
Copy link
Member

am11 commented Nov 17, 2022

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.

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Nov 17, 2022
@ghost
Copy link

ghost commented Nov 17, 2022

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

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 a 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.

Author: am11
Assignees: -
Labels:

area-Meta

Milestone: -

@jkotas
Copy link
Member

jkotas commented Nov 17, 2022

Sounds good to me. Make sure that the shared implementation is at least as fast as the current one.

UCS4

We should not need that.

@jkotas jkotas changed the title Consolidate character encoding implementations Consolidate UTF8 character encoding implementations Nov 17, 2022
@marek-safar
Copy link
Contributor

/cc @SamMonoRT @lateralusX

@ghost
Copy link

ghost commented Nov 23, 2022

Tagging subscribers to this area: @dotnet/area-system-text-encodings-web
See info in area-owners.md if you want to be subscribed.

Issue Details

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.

Author: am11
Assignees: -
Labels:

area-System.Text.Encodings.Web, untriaged

Milestone: -

@am11
Copy link
Member Author

am11 commented Nov 23, 2022

@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.

@ghost
Copy link

ghost commented Nov 23, 2022

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

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.

Author: am11
Assignees: -
Labels:

area-Meta, untriaged

Milestone: -

@jeffhandley
Copy link
Member

Ah; thanks, @am11.

@marek-safar marek-safar removed the untriaged New issue has not been triaged by the area owner label Nov 24, 2022
@marek-safar marek-safar added this to the Future milestone Nov 24, 2022
@marek-safar marek-safar added good first issue Issue should be easy to implement, good for first-time contributors help wanted [up-for-grabs] Good issue for external contributors labels Nov 24, 2022
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Apr 29, 2023
@am11 am11 removed good first issue Issue should be easy to implement, good for first-time contributors help wanted [up-for-grabs] Good issue for external contributors labels May 30, 2023
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jun 22, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Jul 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants