several functions (write_tcp_data, read_tcp_data, read_udp_packets) so that
if it fails and the socket is closed the following code doesn't try to use
the file descriptor.
something with the ares_save_options() where it would try to do a malloc(0)
when no options of that type needed to be saved. On most platforms, this was
fine because malloc(0) doesn't actually return NULL, but on AIX it does, so
ares_save_options would return ARES_ENOMEM.
specific sockets and thus avoiding select() and associated functions/macros.
This function will be used by upcoming libcurl releases for this very
reason. It also made me export the ares_socket_t type in the public ares.h
header file, since ares_process_fd() uses that type for two of the arguments.
(ares_init.c/get_iphlpapi_dns_info() function): when I disable the network
by hand or disconnect the network cable in Windows 2000 or Windows XP, my
application gets 127.0.0.1 as the only name server. The problem comes from
'GetNetworkParams' function, that returns the empty string "" as the only
name server in that case. Moreover, the Windows implementation of
inet_addr() returns INADDR_LOOPBACK instead of INADDR_NONE.
ares_dns.h, which break c-ares on my Sparc64. Bit-wise operations in C
operate on logical values. And in any event the octets are already in
big-endian (aka network) byte order so they're being reversed (thus the
source of the breakage).
things such as C++ compiler actually is a bad thing and since we don't need
that detection I added a work-around, much inspired by a previous patch by
Paolo Bonzini. This also shortens the configure script quite a lot.
Make UDP sockets non-blocking. I've confirmed that at least on Linux 2.4 a
read event can come back from poll() on a valid SOCK_DGRAM socket but
recv(2) will still block. This patch doesn't ignore EAGAIN in
read_udp_packets(), though maybe it should. (This patch was edited by Daniel
Stenberg and a new configure test was added (imported from curl's configure)
to properly detect what non-blocking socket approach to use.)
I'm not quite sure how this was happening, but I've been seeing PTR queries
which seem to return empty responses. At least, they were empty when calling
ares_expand_name() on the record. Here's a patch which guarantees to
NUL-terminate the expanded name. The old behavior failed to NUL-terminate if
len was 0, and this was causing strlen() to run past the end of the buffer
after calling ares_expand_name() and getting ARES_SUCCESS as the return
value. If q is not greater than *s then it's equal and *s is always
allocated with at least one byte.
Yang Tse