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
