[FFmpeg-devel] [PATCH/RFC] Prefer getaddrinfo over gethostbyname

[Martin Storsjö]

On Wed, 20 Jan 2010, M?ns Rullg?rd wrote:

> Martin Storsj? <martin at martin.st> writes:
> 
> >          check_type ws2tcpip.h socklen_t
> >          check_type ws2tcpip.h "struct addrinfo"
> >          check_type ws2tcpip.h "struct sockaddr_storage"
> > +        check_struct winsock2.h "struct sockaddr" sa_len && enable sa_len
> >      else
> >          disable network
> >      fi
> 
> Why the extra enable?  check_struct sets struct_sockddr_sa_len for you.

Ah, I missed that one - yes, then it can be simplified.

> > From 6f378174a22152431158286915cc1f043d4402b9 Mon Sep 17 00:00:00 2001
> > From: Martin Storsjo <martin at martin.st>
> > Date: Wed, 20 Jan 2010 12:54:38 +0200
> > Subject: [PATCH 2/2] Add proper fields to the struct sockaddr_storage replacement
> >
> > These fields follow the recommendation in RFC 3493. The only case
> > they'd break is if the sa_family/sa_len fields of struct sockaddr
> > are located somewhere else than immediately at the beginning of the
> > struct, or if their combined size isn't 2 bytes.
> > ---
> >  libavformat/network.h |   10 +++++++++-
> >  1 files changed, 9 insertions(+), 1 deletions(-)
> >
> > diff --git a/libavformat/network.h b/libavformat/network.h
> > index ea8e946..15e3e70 100644
> > --- a/libavformat/network.h
> > +++ b/libavformat/network.h
> > @@ -70,7 +70,15 @@ int inet_aton (const char * str, struct in_addr * add);
> >  
> >  #if !HAVE_STRUCT_SOCKADDR_STORAGE
> >  struct sockaddr_storage {
> > -    struct sockaddr_in x;
> > +#if HAVE_SA_LEN
> > +    uint8_t ss_len;
> > +    uint8_t ss_family;
> > +#else
> > +    uint16_t ss_family;
> > +#endif
> > +    char __ss_pad1[6];
> > +    int64_t __ss_align;
> > +    char __ss_pad2[112];
> >  };
> >  #endif
> 
> You can't have names starting with __.
> 
> Why don't you use the system struct sockaddr instead of trying to
> replicate it?  If it's not big enough for ipv6 addresses, the system
> clearly doesn't support ipv6 in the first place.

The problem is that socket family agnostic code may want to use struct 
sockaddr_storage as a generic container which can hold any type of 
sockaddr returned by the system calls. Even if a system doesn't support 
ipv6, generic code may need to use sockaddr_storage - udp.c uses it at the 
moment in the ipv6 codepath, that I'm trying to make the general case for 
all cases.

But yes, it doesn't need to be that big, the size of a normal IPv4 
sockaddr_in would be enough in these cases.

If only used as a container, only the size would matter, and the current 
version which simply wraps a sockaddr_in, but RFC 3493 also specifies that 
this struct sockaddr_storage should have the field ss_family.

So, if the system doesn't provide a definition of sockaddr_storage, we'd 
need to define a replacement, which can fit at least sockaddr_in, and 
which has a field named ss_family, located at the same offset and with the 
same size as sa_family in the generic sockaddr.

Another solution, which I proposed earlier,
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-January/081039.html,
is to simply avoid accessing the fields of sockaddr_storage, by only using 
it through casts to the generic sockaddr (which always is available).

// Martin