curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Is EBCDIC support gone?

From: David Woodhouse via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 20 Jul 2022 18:05:41 +0100

On Wed, 2022-07-20 at 12:29 +0200, Patrick Monnerat via curl-library wrote:
> On 7/20/22 12:11, Daniel Stenberg via curl-library wrote:
> > On Wed, 20 Jul 2022, Stephan Mühlstrasser via curl-library wrote:
> > > Do I understand it correctly that EBCDIC support is gone now in general?
> >
> > Yes, that is correct.
>
> This is true: libcurl internally only works on ASCII-based character sets.

Hm, I don't understand how "works on ASCII-based character sets" is a
thing that makes sense to say.

If there is *any* legacy 8-bit character set in use, whether it's
ASCII-based or not, we still have to take care with conversions,
surely?

In OpenConnect I have specific tests for this kind of thing. I have a
test client cert with a password 'ĂŻ', which is two characters:
 
  U+0102 LATIN CAPITAL LETTER A WITH BREVE
  U+017B LATIN CAPITAL LETTER Z WITH DOT ABOVE

In UTF-8 that's represented by the bytes 0x02 0x01 0x7b 0x01.
In ISO8859-2 it would just be two bytes: 0xc3 0xaf.

I have tests which set $LANG and try to use the correct password. You
can't just say they're both "ASCII-based" and pray to the deity of your
choice, surely?

In any setup that actually *works,* EBCDIC is just a trivially-special
case of the general case of needing conversion.

If it only works for 7-bit ASCII characters, that isn't "works".



-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
  • application/pkcs7-signature attachment: smime.p7s
Received on 2022-07-20