[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