[FFmpeg-devel] [PATCH] IPv6 support v.2
Ronald S. Bultje
Thu Nov 8 20:04:23 CET 2007
On Nov 8, 2007 1:41 PM, Nicolas George <nicolas.george at normalesup.org>
> L'octidi 18 brumaire, an CCXVI, Ronald S. Bultje a ?crit:
> > I added flags to force that already, see AV_RESOLVE_IPVONLY.
> 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
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
> headers. I think I would be more at ease with get_port and set_port
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
> > 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
> > IPv4 and IPv6.
> Again, hardcoding the offset of a structure member does not seem a sane
> of coding to me.
> But I am wondering: what could the caller possibly do with just the
> 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).
More information about the ffmpeg-devel