Attached a little patch needed for current cvs in order to compile on
windows nt 4 (any system without IPV6 really).
Changelog:
connect.c (socket_has_inet6): don't use AF_INET6 without ENABLE_IPV6
main.c (main): don't test opt.ipv[46]_only without ENABLE_IPV6
Heiko
--
--
Herold Heiko [EMAIL PROTECTED] writes:
Attached a little patch needed for current cvs in order to compile
on windows nt 4 (any system without IPV6 really).
Thanks. Note that the function isn't even called when IPv6 is
unavailable, so you can feel free to wrap the entire function in
#ifdef
Herold Heiko [EMAIL PROTECTED] said:
Attached a little patch needed for current cvs in order to compile on
windows nt 4 (any system without IPV6 really).
FYI, Wget/IPv6 on Windows do work somewhat; getaddrinfo()
is able to resolve a host to it's IPv6 address(es). But getnameinfo()
isn't able
Gisle Vanem [EMAIL PROTECTED] writes:
Due to lack of inet_ntop() on Windows, I used this instead:
struct sockaddr_in6 addr6;
addr6.sin6_family = AF_INET6;
memcpy (addr6.sin6_addr, address, sizeof(addr6.sin6_addr));
if (getnameinfo ((const struct sockaddr*)addr6, sizeof(addr6),
but Wget doesn't check return value of inet_ntop(). Hint hint.
I wasn't aware that inet_ntop could really fail. Why did getaddrinfo
return the address if I can't print it?
getaddrinfo() on Win-XP seems to be a thin wrapper over the DNS
client which resolves records fine. But
Gisle Vanem [EMAIL PROTECTED] writes:
but Wget doesn't check return value of inet_ntop(). Hint hint.
I wasn't aware that inet_ntop could really fail. Why did
getaddrinfo return the address if I can't print it?
getaddrinfo() on Win-XP seems to be a thin wrapper over the DNS
client which
On Wed, 8 Oct 2003, Hrvoje Niksic wrote:
Mauro Tortonesi [EMAIL PROTECTED] writes:
I still don't understand the choice to use sockaddr and
sockaddr_storage in a application code.
They result in needless casts and (to me) uncomprehensible code.
well, using sockaddr_storage is the right
Mauro Tortonesi [EMAIL PROTECTED] writes:
and i'm saying that for this task the ideal structure is
sockaddr_storage. notice that my code uses sockaddr_storage
(typedef'd as wget_sockaddr) only when dealing with socket
addresses, not for ip address caching.
Now I see. Thanks for clearing it
On Fri, 10 Oct 2003, Hrvoje Niksic wrote:
Mauro Tortonesi [EMAIL PROTECTED] writes:
An IPv4 address is nothing more than a 32-bit quantity. I don't
see anything incorrect about using unsigned char[4] for that, and
that works perfectly fine on 64-bit architectures.
ok, but in this way
here is my first patch to improve ipv6 support of wget. please, notice
that the code compiles, but is still buggy and will probably not work.
i am sending this preliminary patch only to gather feedback from wget
developers and to coordinate with other developers who are working on
ipv6 support
Mauro Tortonesi [EMAIL PROTECTED] writes:
so, i am asking you: what do you think of these changes?
Overall they look very good! Judging from the patch, a large piece of
the work part seems to be in an unexpected place: the FTP code.
Here are some remarks I got looking at the patch.
It
On Wed, 8 Oct 2003, Hrvoje Niksic wrote:
Mauro Tortonesi [EMAIL PROTECTED] writes:
so, i am asking you: what do you think of these changes?
Overall they look very good! Judging from the patch, a large piece of
the work part seems to be in an unexpected place: the FTP code.
yes, i have
Mauro Tortonesi [EMAIL PROTECTED] writes:
I still don't understand the choice to use sockaddr and
sockaddr_storage in a application code.
They result in needless casts and (to me) uncomprehensible code.
well, using sockaddr_storage is the right way (TM) to write IPv6 enabled
code ;-)
Not
Mauro Tortonesi wrote:
are there __REALLY__ systems which do not support inet_aton? their ISVs
should be ashamed of themselves...
Solaris, for example. IIRC inet_aton isn't in any document which claims
to be a standard.
however, yours seemed to me an ugly hack, so i have temporarily removed
[EMAIL PROTECTED] writes:
sockaddr_in and sockaddr_in6 carries needless baggage such as the
port number and the family. There is no reason to cache all that.
to me, they are not needless, it is easier when we carry them
together.
I can't believe extracting the address would be
[EMAIL PROTECTED] writes:
with IPv6-capable API host name resolution is done by
getaddrinfo(3) functions, not gethostbyname(3). they return
sockaddrs, therefore it is more natural/easier to carry around
sockaddrs.
It sounds like a random implementation convenience in
Jun-ichiro itojun Hagino [EMAIL PROTECTED] writes:
hello, a patch to support IPv6 in wget 1.7 can be found at:
ftp://ftp.kame.net/pub/kame/misc/
Thanks. I must admit that I'm a bit overwhelmed by this patch.
Several questions:
* Would you be willing to take a look at the sources
[EMAIL PROTECTED] writes:
yes, I can redo patch for the latest CVS tree, but I'd need
more info on anoncvs access.
Take a look at http://wget.sunsite.dk/. It explains how to download
the latest sources from CVS.
[EMAIL PROTECTED] writes:
looking at 1.8, i noticed that host handling needs a total
re-engineering.
I don't believe this. But I could be missing something.
we should be carrying around sockaddrs (not in_addr)
for IPv4/v6 support
The struct address_list was
19 matches
Mail list logo
