[RFC] Adding a char set converter to Support library

Kai,

   I added some comments to your patch, but my main takeaway is that I think the iconv dependency should probably be removed regardless of license uncertainty. I think we should define a set of conversions that we support and only support those. If convertWithTable is good enough for us, then we don't need iconv. From what I can tell by reading the code, iconv provides the possibility of supporting additional conversions. However, if CharSetConverter::create can return a converter on one person's machine, but not mine because I don't have an optional dependency installed, that's going to be very annoying.

Thanks,
   Christopher Tetreault

I see that there is a great emphasis on deterministic behavior on all
platforms.
I'll update my code accordingly, as there is no need to have more
conversions right now.
It also make the change much smaller.

Thanks for all the comments!

Regards,
Kai

Kai,

   I added some comments to your patch, but my main takeaway is that
I think the iconv dependency should probably be removed regardless
of license uncertainty. I think we should define a set of
conversions that we support and only support those. If
convertWithTable is good enough for us, then we don't need iconv.
From what I can tell by reading the code, iconv provides the
possibility of supporting additional conversions. However, if
CharSetConverter::create can return a converter on one person's
machine, but not mine because I don't have an optional dependency
installed, that's going to be very annoying.

Thanks,
   Christopher Tetreault

From: llvm-dev <llvm-dev-bounces@lists.llvm.org> On Behalf Of Kai
Peter Nacke via llvm-dev
Sent: Friday, October 2, 2020 10:45 AM
To: Anton Korobeynikov <anton@korobeynikov.info>
Cc: llvm-dev <llvm-dev@lists.llvm.org>; Yusra Syeda

<Yusra.Syeda@ibm.com>

Subject: [EXT] Re: [llvm-dev] [RFC] Adding a char set converter to
Support library

My understanding is that dynamically linking should pose no problem,
but I am no lawyer. On Linux, glibc is also under LGPL license, and
LLVM usually links against it.
(There is really no need for us to depend on libiconv. If it is
deemed to risky, then I can dropped it.)

From: Anton Korobeynikov <anton@korobeynikov.info>
To: Kai Peter Nacke <kai.nacke@de.ibm.com>
Cc: llvm-dev <llvm-dev@lists.llvm.org>, Yusra Syeda
<Yusra.Syeda@ibm.com>
Date: 02.10.2020 19:08
Subject: [EXTERNAL] Re: [llvm-dev] [RFC] Adding a char set
converter to Support library

As far as I remember, libiconv is under LGPL. Will this cause any

troubles?

>
> Hi!
>
> On z/OS, there is the need to convert strings from EBCDIC to UTF-8 and
> vice versa.
> Using the POSIX iconv functions has some challenges, so I created a
small
> wrapper
> around this functionality to get the same result on all platforms.
> This functionality is required for reading and writing GOFF object
> files and can also be
used
> in the
> frontend.
> I put up the code on Phabricator
INVALID URI REMOVED
u=https-3A__reviews.llvm.org_D88741&d=DwIGaQ&c=jf_iaSHvJObTbx-
siA1ZOg&r=43FMMTMN1rMQYLfzcfWYI9JmFbjyCLLZVkpxUNJkDuQ&m=sWBaZY-

XUunyyPTGF0O0RoXv4zr8Jhs_12PiXnHZssY&s=ToJNhho_wxlsDmdRsG0Eimm9nAIr_be4wlwM6SGo2c4&e=

. Please
> add your
> comments to the review if you are interested in this topic.
>
> Best regards,
> Kai
>
> Kai Nacke
> IT Architect
>
> IBM Deutschland GmbH
> Vorsitzender des Aufsichtsrats: Sebastian Krause
> Geschäftsführung: Gregor Pillen (Vorsitzender), Agnes Heftberger,
Norbert
> Janzen, Markus Koerner, Christian Noll, Nicole Reimer Sitz der
> Gesellschaft: Ehningen / Registergericht: Amtsgericht
Stuttgart,
> HRB 14562 / WEEE-Reg.-Nr. DE 99369940
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev@lists.llvm.org
>
INVALID URI REMOVED

u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-

siA1ZOg&r=43FMMTMN1rMQYLfzcfWYI9JmFbjyCLLZVkpxUNJkDuQ&m=sWBaZY-

XUunyyPTGF0O0RoXv4zr8Jhs_12PiXnHZssY&s=KyVectWeKXSputV9dDx46gCXj6AavdtD0LGW4XexTTM&e=

--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University

_______________________________________________
LLVM Developers mailing list
llvm-dev@lists.llvm.org
INVALID URI REMOVED

u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-

siA1ZOg&r=43FMMTMN1rMQYLfzcfWYI9JmFbjyCLLZVkpxUNJkDuQ&m=sWBaZY-

XUunyyPTGF0O0RoXv4zr8Jhs_12PiXnHZssY&s=KyVectWeKXSputV9dDx46gCXj6AavdtD0LGW4XexTTM&e=

Kai,

I added some comments to your patch, but my main takeaway is that I think the iconv dependency should probably be removed regardless of license uncertainty. I think we should define a set of conversions that we support and only support those. If convertWithTable is good enough for us, then we don’t need iconv. From what I can tell by reading the code, iconv provides the possibility of supporting additional conversions. However, if CharSetConverter::create can return a converter on one person’s machine, but not mine because I don’t have an optional dependency installed, that’s going to be very annoying.

That’s a good argument for having a mapping of recognized encoding identifiers as part of the configuration or packaging process. I am not sure this makes the case for avoiding iconv entirely.