cURL / Mailing Lists / curl-library / Single Mail


Re: ebcdic and tpf patches

From: David McCreedy <>
Date: Wed, 05 Apr 2006 21:59:06 +0000

Attached is a new EBCDIC/TPF patch with changes addressing most of Dan
Fandrich's comments.
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
each select.
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
>config file.


>Do there really need to be two separate but equal definitions of

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
different character.

>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
test on.
Can this limitation be noted and addressed by the first threaded platform
that needs to do conversions?
Received on 2006-04-06