Attached is a new EBCDIC/TPF patch with changes addressing most of Dan
Fandrich's comments.
See below for new details.

-David

On Thu, Mar 30, 2006 23:44:25 -0800, Dan Fandrich wrote:

>The #define select is pretty dangerous. Turning that into two function
>calls
>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
nothing.

>There's a #define VERSION in the config file that shouldn't be in a static
>config file.

Fixed.

>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
>easier
>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
>cause
>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