This is an archive of the discontinued LLVM Phabricator instance.

New CharSetConverter wrapper class for ConverterEBCDIC
Needs ReviewPublic

Authored by abhina.sreeskantharajan on Jun 21 2023, 6:18 AM.

Details

Summary

This patch is adding a wrapper class called CharSetConverter for ConverterEBCDIC which was added previously here https://reviews.llvm.org/rGb42718dcecdd6787e0fde826ef7377f4e3cdd7bd.

This is the base for two patches, the first will add-on iconv support to this CharSetConverter class so we can support more charsets (https://reviews.llvm.org/D153418). The other patch is the implementation of fexec-charset (https://reviews.llvm.org/D153419) which relies on this CharSetConverter class.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptJun 21 2023, 6:18 AM
abhina.sreeskantharajan requested review of this revision.Jun 21 2023, 6:18 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 21 2023, 6:18 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

As I mentioned at https://discourse.llvm.org/t/rfc-enabling-fexec-charset-support-to-llvm-and-clang-reposting/71512 , I think SimplifyLibCalls needs to be aware of encodings. To make that work, this probably needs to be somewhere in llvm/ , not clang/ .

As I mentioned at https://discourse.llvm.org/t/rfc-enabling-fexec-charset-support-to-llvm-and-clang-reposting/71512 , I think SimplifyLibCalls needs to be aware of encodings. To make that work, this probably needs to be somewhere in llvm/ , not clang/ .

There was previous resistance to putting this in LLVM https://discourse.llvm.org/t/rfc-adding-a-charset-converter-to-the-llvm-support-library/69795/17, I'm not sure if that sentiment has changed. I think it would be best to have some sort of implementation plan to tackle the SimplifyLibCalls issue before shifting this code

As I mentioned at https://discourse.llvm.org/t/rfc-enabling-fexec-charset-support-to-llvm-and-clang-reposting/71512 , I think SimplifyLibCalls needs to be aware of encodings. To make that work, this probably needs to be somewhere in llvm/ , not clang/ .

There was previous resistance to putting this in LLVM https://discourse.llvm.org/t/rfc-adding-a-charset-converter-to-the-llvm-support-library/69795/17, I'm not sure if that sentiment has changed. I think it would be best to have some sort of implementation plan to tackle the SimplifyLibCalls issue before shifting this code

I don't think anyone is particularly against the concept of adding a charset conversion API; most of the discussion is around the choice to implement the API as a thin wrapper around POSIX iconv(). And that concern applies equally no matter where the code is located in the source tree.

I don't think anyone is particularly against the concept of adding a charset conversion API; most of the discussion is around the choice to implement the API as a thin wrapper around POSIX iconv(). And that concern applies equally no matter where the code is located in the source tree.

Sorry, I misremembered where it was. That discussion I mentioned was from the previous patch https://reviews.llvm.org/D88741, not my RFC.

@cor3ntin had the following concerns:

If we do use iconv though, i would like us to have a better understanding of use cases, The patch currently links iconv to all llvm libraries, which might be overkill if the only project using it is Clang, and I wonder how that affects packaging
on linux distributions.