On Thu, Jun 07, 2018 at 09:01:15PM +0200, Richard Levitte wrote: > We don't have to answer the question "how high" now. I'm fully > prepared to have the use of iconv limited to platforms where we know > it's available (for example, we - or well, *I* - know that VMS has the > iconv API in the C RTL, not even any need to link with any extra > library... and we *know* it's available in glibc since version > 2.something). I'm fully prepared to have to deal with people saying > "hey, we have that too!" and having to edit config targets as we go. > I do not expect any support of iconv to cover more than what we can > test or get patches for, as with anything else.
There's also apparently some variation in the iconv API function prototypes (possibly "const char **" vs. "char **"). So some platform-dependent casting may be required... My peers suggest that this late in the release cycle, we leave the responsibility of ensuring UTF-8 input to the user. We could describe work-arounds in documentation. Personally, if this is off by default, and requires a new option to enable, and is just in openssl(1) and not libcrypto, I'm disinclined to say "no" until I see a PR (with documentation) that we can decide to leave for post 1.1.1 or adopt. -- Viktor. _______________________________________________ openssl-project mailing list email@example.com https://mta.openssl.org/mailman/listinfo/openssl-project