[SSSD] [PATCH] resolv: Do not try to free addrinfo in case of error

Jakub Hrozek jhrozek at redhat.com
Tue Jun 3 11:47:51 UTC 2014


On Mon, May 19, 2014 at 11:11:36AM +0200, Jakub Hrozek wrote:
> On Mon, May 19, 2014 at 07:52:05AM +0200, Lukas Slebodnik wrote:
> > On (18/05/14 04:58), Jakub Hrozek wrote:
> > >On Sat, 2014-05-17 at 19:38 +0200, Lukas Slebodnik wrote:
> > >> ehlo,
> > >> 
> > >> We should call freeaddrinfo only in situation if getaddrinfo succeeds.
> > >> It is not specified in RFC2553 the behaviour of calling freeaddrinfo
> > >> with the NULL argument. It is more portable to do not rely on undocumented
> > >> behaviour of glibc.
> > >> 
> > >> http://www.ietf.org/rfc/rfc2553.txt [Page 28]
> > >> 
> > >> simple patch is attached.
> > >> 
> > >> LS
> > >
> > >While the behaviour with the NULL argument is not explicitly spelled
> > >out, I don't see the RFC saying that the behaviour is undefined either.
> > >
> > >Is there really any platform where a free* function would not be a noop?
> > 
> > POSIX functions don't require you to zero the pointers used for output unless
> > specified otherwise.
> > 
> > From [1]:
> > 
> >     Upon successful return of getaddrinfo(), the location to which res points
> >     shall refer to a linked list of addrinfo structures, each of which shall
> >     specify a socket address and information for use in creating a socket with
> >     which to use that socket address.
> > 
> > It's pretty clear that the standard is written with an assumption that in
> > other cases, the res variable is not being touched. In other way. it does not
> > make a sense to call freeaddrinfo, if getaddrinfo fails.
> > 
> > The one of possible implementation where calling freeaddrinfo(NULL) will crash.
> > http://ftp.fr.openbsd.org/pub/OpenBSD/src/lib/libc/net/freeaddrinfo.c
> > 
> > 
> > [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html
> > 
> > LS
> 
> OK, thanks. Then I think your patch makes sense.
> 
> ACK

Pushed to sssd-1-11: 6f895da367934fe44e101d8bc3d7dcee11034f3b



More information about the sssd-devel mailing list