Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

curl_ctype: private is*() type macros and functions #2269

Closed
wants to merge 4 commits into from

Conversation

bagder
Copy link
Member

@bagder bagder commented Jan 29, 2018

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

... since the libc provided one are locale dependent in a way we don't
want.
@bagder
Copy link
Member Author

bagder commented Jan 29, 2018

Ah, it needs some more polish...

@monnerat
Copy link
Contributor

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
Copy link
Member Author

bagder commented Jan 29, 2018

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 bagder closed this in 4272a0b Jan 29, 2018
@bagder bagder deleted the bagder/curl_ctype branch January 29, 2018 21:59
@MarcelRaad
Copy link
Member

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
Copy link
Member Author

bagder commented Mar 2, 2018

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

MarcelRaad added a commit to MarcelRaad/curl that referenced this pull request Mar 3, 2018
On MinGW and Cygwin, GCC and clang have been complaining about macro
redefinitions since 4272a0b. Fix this
by undefining the macros before redefining them as suggested in
curl#2269.

Suggested-by: Daniel Stenberg
@lock lock bot locked as resolved and limited conversation to collaborators May 31, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants