djgpp has locale.h and setlocale().

fine even for third party transfers.

Added Traian Nicolescu's patches for threaded resolver on
Windows. Plugged some potential handle and memory leaks.

Refs.
  http://curl.haxx.se/mail/lib-2004-10/0134.html
  http://curl.haxx.se/mail/lib-2004-10/0157.html

and password fields properly in URLs, like
ftp://us?er:pass?word@site.com/. Added test 191 to verify the fix.

Set errno = ENOMEM on faild countcheck().

by gcc 3.4

MSVC uses 'i64' suffix for 64-bit sizes.

our strtoll() replacement function.

Andy Cedilnik reported. Warning on HP-UX?

warnings.

our own in the formdata.c file to prevent warnings on systems without it

work with libidn < 0.5.6

Fixed tld_check_name(). idna_to_unicode_lzlz() should never fail,
but return FALSE if 'uc_name == NULL' just in case.

USE_LIBIDN: Added Top-level-domain (TLD) check for host->name.
Only print a warning if check fails.

CURLOPT_FOLLOWLOCATION, libcurl reported error if a redirect happened even if
the new URL would provide the resumed file. Test case 188 added to verify the
fix (together with existing test 99).

djgpp has basename()

about code that won't be reached

Mainly meant to deal with the IRIX case which seems to requrie a "-lgen" lib
to find the basename function and thus without the gen lib, it finds the
header but not the function and our replacement function has a prototype
that doesn't match the IRIX one.

A different approach would be to make configure detect and use -lgen for the
systems that require it.

allow verbose output during this period. Bertrand Demiddelaer reported and
helped fixing.

the multi-threaded resolver does wrong

data as 'char *' and that makes us pass in negative values if there is 8bit
data in the string. Changing to unsigned causes too much warnings or too many
required typecasts to the normal string functions.

based) IDN conversion fails. This is really due to a missing suitable
function in the libidn API that I hope we can remove once libidn gets a
function like this.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134133) and not to anyone
involved in the curl project! This happens when you try to curl a file from a
proftpd site using SSL. It seems proftpd sends a somewhat unorthodox PASS
response code (232 instead of 230). I relaxed the response code check to deal
with this and similar cases.