Re: ebcdic and tpf patches
Date: Fri, 31 Mar 2006 00:43:34 +0000
On Thu, Mar 30, 2006 23:44:25 -0800, Dan Fandrich wrote:
>I have a few comments after a quick read-through. I'm actually surprised
>how clean this patch is, considering the contorsions it's putting the data
>through for such an oddball architecture. Does it properly convert user
>specified data, such as the -H and -u options, too?
It converts on the -u. I don't know about -H since the TPF port is only for
FTP at present and -H shows up as an HTTP option.
>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).
Right. I had lucked out on the calls but it's not a good solution moving
I'll work up a better fix in April.
>The definition of unescape_elements() is still taking a void *data, not
>CURL *data as Daniel suggested.
Actually, Daniel's suggestion was for the curl_[un]escape functions, which
are now curl_easy_[un]escape and do take CURL*.
The unescape_elements function is internal to ldap.c.
I noticed that ldap.c used void* internally and followed suit.
I can easily make it a CURL* but that seemed a bit incongruent to me.
>There's a #define VERSION in the config file that shouldn't be in a static
I'll change that to #define VERSION "not-used" to mimic config-vms.h.
I noticed config-riskos.h #undef's it. I'm not sure which approach is
It doesn't seem to matter either way.
>Do there really need to be two separate but equal definitions of
>CURL_ICONV_CODESET_OF_NETWORK and CURL_ICONV_CODESET_FOR_UTF8?
Doh! CURL_ICONV_CODESET_FOR_UTF8 shouldn't have been copied into src/main.c
since it only uses CURL_ICONV_CODESET_OF_NETWORK.
And I too don't like defining it in two different places.
But I couldn't find a header file that lib/easy.c and src/main.c share,
which is the logical place to put it.
>The error message "conversion failed" is pretty generic; what kind of
>conversion? Maybe it's good enough given that conversion is probably only
>used in curl for this.
And the platforms that use conversion will be well aware of it.
>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.
I know very little about threads. What would be a good solution?
Would moving the _cd fields to the SessionHandle make this thread safe?
>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?
I was following the current code, which uses a '.' for unprintable
characters but that's easy to change if it's useful.
Received on 2006-03-31