15 Dec
2011
15 Dec
'11
4:21 p.m.
On 12/15/2011 04:41 PM, Daniel-Constantin Mierla wrote:
Hello,
On 12/15/11 1:18 PM, marius zbihlei wrote:
Hello,
Even if inet_pton() can't use our existing structure, but it can use an
in6_addr structure (size is 16 bytes) that can be easily converted into
our internal representation (keep in mind endianess and other constraints).
I will have a look when I implement it and will test the changes.
Cheers,
Marius
--
Zbihlei Marius
Head of
Linux Development Services Romania
1&1 Internet Development srl Tel KA: 754-9512
Str Mircea Eliade 18 Tel RO: +40-31-223-9512
Sect 1, Bucuresti mailto: marius.zbihlei(a)1and1.ro
71295, Romania
On 12/14/2011 07:28 PM, Andreas Granig wrote:
have you checked if
inet_pton() doesn't break the internal ip_addr
structure and the use of it? If all is ok, I guess inet_pton() is
portable enough through most unix/linux distro's to make use of it.
Cheers,
Daniel
Hey Dani
Hello,
Actually, looking at the code I've observed some weird behavior : for
example to fix the force_send_socket IPv6 address, a call to str2ip6()
(from resolve.h) is done (via resolvehost()). The function tries to
manually parse the IP address, so it makes me wonder why not use a
library function like inet_pton(AF_INET6... to get the correct structure.
A possible bug is that with the current code, IPv4 mapped to IPv6
(x:x:x:x:x:x:d.d.d.d) will not be parsed correctly.
Why don't we use inet_pton(AF_INET6 ... . Any reasons?