Re: ebcdic and tpf patches
Date: Wed, 05 Apr 2006 21:59:06 +0000
Attached is a new EBCDIC/TPF patch with changes addressing most of Dan
See below for new details.
On Thu, Mar 30, 2006 23:44:25 -0800, Dan Fandrich wrote:
>The #define select is pretty dangerous. Turning that into two function
>is going to cause problems (e.g. for (i=0; i<RETRY; ++i) select(a,b,c,d,e);
>won't do what you want).
The purpose of making two calls is so tpf_process_signals is called after
This kludge is OK with all of the select calls currently in Curl, but I've
worked up a better fix.
It adds "curl_check_signals" calls after the selects, which has the same
effect as the previous patch.
On TPF, curl_check_signals is #defined to tpf_process_signals.
On all other platforms the curl_check_signals calls get #defined away to
>There's a #define VERSION in the config file that shouldn't be in a static
>Do there really need to be two separate but equal definitions of
>CURL_ICONV_CODESET_OF_NETWORK and CURL_ICONV_CODESET_FOR_UTF8?
No. I've removed the definition in src/main.c as it was unused.
>How about making the non-printable ASCII '.' dot be a macro, to make it
>to change on those platforms where another character might be more accepted
>for the purpose?
Done. UNPRINTABLE_CHAR will default to '.' if a platform doesn't define a
>Aren't the global variables outbound_cd, inbound_cd and utf8_cd going to
>problems in multithreaded programs? It looks to me like they could be
>written to simultaneously by two threads.
Yes that could be a problem for mutli-threaded programs.
TPF's use of Curl does not utilize threads, so it's not a issue.
I looked through Curl code such as curl_lock_data but don't think I can come
up with an efficient solution without knowledge of threads and a platform to
Can this limitation be noted and addressed by the first threaded platform
that needs to do conversions?
Received on 2006-04-06