# \[RFC\] Adding a CharSet Converter to the LLVM Support Library

**URL:** <https://discourse.llvm.org/t/rfc-adding-a-charset-converter-to-the-llvm-support-library/69795>\
**Category:** LLVM Project\
**Created:** [April 5, 2023, 9:57pm UTC](https://discourse.llvm.org/t/rfc-adding-a-charset-converter-to-the-llvm-support-library/69795 "2023-04-05T21:57:09Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![AaronBallman](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/aaronballman/32/13680_2.png) [@AaronBallman](https://discourse.llvm.org/u/AaronBallman)\
**Post date:** [April 24, 2023, 7:27pm UTC](https://discourse.llvm.org/t/rfc-adding-a-charset-converter-to-the-llvm-support-library/69795/16 "2023-04-24T19:27:23Z")

</div>

My primary concern with that approach is how compatible the results are across libraries. e.g., it would be really bad if the same input text and same target encoding produced different results depending on what platform the host compiler was on. However, I’m not certain how likely such an outcome is.

But in general, it’s not a problem using different libraries on different platforms. We have a reasonable number of APIs in `llvm/Support` that have a UNIX branch and a Windows branch that use different implementation strategies for platform-specific needs. Text encoding isn’t quite as platform-specific as threads or file system support, but it is tied somewhat to the platform in terms of what library offerings are available.

---

_[View the full topic](https://discourse.llvm.org/t/rfc-adding-a-charset-converter-to-the-llvm-support-library/69795)._