[FFmpeg-devel] [PATCH] IPv6 support v.2

[Ronald S. Bultje]

Hi,

On Nov 8, 2007 1:41 PM, Nicolas George <nicolas.george at normalesup.org>
wrote:

> L'octidi 18 brumaire, an CCXVI, Ronald S. Bultje a ?crit:
> > I added flags to force that already, see AV_RESOLVE_IPV[46]ONLY.
>
> I do not like that interface: that means that the caller has to set the
> correct AV_* flag according to the AF_* value. Which implies it knows the
> mapping between all possible AF_* and AV_RESOLVE_*ONLY. That breaks
> protocol
> independence.


Only those two are supported anyway. Calls like getaddrinfo() don't support
any others. But I can sort of see your point, I could add a macro like
AV_RESOLVE_FAMILY(addr) which sets the flag:

#define AV_RESOLVE_FAMILY(addr) \
    addr->addr->sa_family == AF_INET ? AV_RESOLVE_IPV4ONLY :
    (addr->addr->sa_family == AF_INET6 ? AV_RESOLVE_IPV6ONLY : 0)

A reverse macro for use inside inetaddr_resolve() could also be done,
although I'd consider it overkill already. Would that be OK for you?


> > No, the offset is the same for IPv4 and IPv6.
>
> There is absolutely no guarantee of that in any standard that I know.
> Relying on it would make the code quite fragile.
>
> Something like:
>
>        *(a->family == AF_INET ?
>          &((struct sockaddr_in *) a->addr)->sin_port :
>          &((struct sockaddr_in6 *) a->addr)->sin6_port)
>
> would probably be much more reliable.
>
> But doing it as a macro would require that the caller has all the
> necessary
> headers. I think I would be more at ease with get_port and set_port
> macros.
>

Your macro is equally fine with me, and does indeed look safer. I think the
header mess is why I did it this way. We can make two macros, one for if
it's there (inet6/in6.h) and one for if it isn't, it's not that bad.


> > The offset of the address from the data in the sockaddr_in and
> sockaddr_in6
> > struct. In both cases, there's a 16-bit port number, but after that, the
> > address follows directly in the sockaddr_in structure, whereas there's
> > another 32 bits in between for sockaddr_in6. Hence the different offset
> for
> > IPv4 and IPv6.
>
> Again, hardcoding the offset of a structure member does not seem a sane
> way
> of coding to me.
>
> But I am wondering: what could the caller possibly do with just the
> address,
> like that? To do something useful with the address, it would require at
> least its size, and again, that breaks protocol independence.
>

It's for ffserver, it does ACL checks using this thing. Other than that, it
shouldn't be used, and it isn't used, except in inet_ntop() inside
inetaddr_str() (and yes that's how you're supposed to do it, apparently,
it's a bit ugly... Ohwell).

Ronald