curl_ctype: private is*() type macros and functions

[bagder]

... since the libc provided one are locale dependent in a way we don't
want.

[bagder]

Ah, it needs some more polish...

[bagder]

Ah, it needs some more polish...

[monnerat]

I have spoken too fast on the mailing list: we have to make provision for EBCDIC support (CURL_DOES_CONVERSION), thus we have to support all values <= 0xFF. EBCDIC uses the full 8-bit range so the table should have 256 entries and a conditional (#if '0' == '\xF0' --> EBCDIC) to enable one table or another.

Variants of EBCDIC:

• Code page 37: US ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00037.pdf
• Code page 500: Europe ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00500.pdf
• Code page 297: France ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00297.pdf

plus many others.

AFAIK, only non alnum codes may vary from one CP to another.

OS400 libcurl uses ASCII. We should probably ask the TPF maintainer about it.

[monnerat]

I have spoken too fast on the mailing list: we have to make provision for EBCDIC support (CURL_DOES_CONVERSION), thus we have to support all values <= 0xFF. EBCDIC uses the full 8-bit range so the table should have 256 entries and a conditional (#if '0' == '\xF0' --> EBCDIC) to enable one table or another.

Variants of EBCDIC:

• Code page 37: US ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00037.pdf
• Code page 500: Europe ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00500.pdf
• Code page 297: France ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00297.pdf

plus many others.

AFAIK, only non alnum codes may vary from one CP to another.

OS400 libcurl uses ASCII. We should probably ask the TPF maintainer about it.

[bagder]

I figure EBCDIC gets its own set of functions, or possibly even get to use the original functions. I don't intend to work on those versions since I don't have any such hardware to test on so it'll certainly end up wrong somewhere anyway.

[bagder]

I figure EBCDIC gets its own set of functions, or possibly even get to use the original functions. I don't intend to work on those versions since I don't have any such hardware to test on so it'll certainly end up wrong somewhere anyway.

[MarcelRaad]

I get redefinition warnings/errors now on MinGW-MSYS as well as Cygwin:

curl_ctype.c:25:0: Fehler: »_U« redefiniert [-Werror]
 #define _U (1<<0) /* upper case */

In file included from curl_setup_once.h:34:0,
                 from curl_setup.h:695,
                 from curl_ctype.c:23:
/usr/include/ctype.h:60:0: Anmerkung: dies ist die Stelle der vorherigen Definition
 #define _U 01

(Wow, why does my GCC speak German all of a sudden?)

[MarcelRaad]

I get redefinition warnings/errors now on MinGW-MSYS as well as Cygwin:

curl_ctype.c:25:0: Fehler: »_U« redefiniert [-Werror]
 #define _U (1<<0) /* upper case */

In file included from curl_setup_once.h:34:0,
                 from curl_setup.h:695,
                 from curl_ctype.c:23:
/usr/include/ctype.h:60:0: Anmerkung: dies ist die Stelle der vorherigen Definition
 #define _U 01

(Wow, why does my GCC speak German all of a sudden?)

[bagder]

I think we should probably first #undef all those defines to make sure they're not colliding like for you...

[bagder]

I think we should probably first #undef all those defines to make sure they're not colliding like for you...