Date: Wed, 27 Feb 2002 23:07:27 -0800 From: Rob Braun <bbraun@synack.net> To: Hajimu UMEMOTO <ume@mahoroba.org> Cc: freebsd-net@freebsd.org Subject: Re: proposed changes to getnameinfo() implementation Message-ID: <200202280707.g1S77Rg27514@lh.synack.net> In-Reply-To: Your message of Thu, 28 Feb 2002 15:07:44 %2B0900
next in thread | raw e-mail | index | archive | help
On Thursday, Feb 2002 at 15:7:44 Hajimu UMEMOTO wrote: > > RFC2553 defines two types of struct sockaddr, one has sa_len and the > other doesn't has it. Though we *BSD has sa_len, non-BSD doesn't have > it. Regardless of sa_len, the size of the structure is already known by the value of sa_family, which both sockaddrs have. > To keep the portability of the application, we must set the size of > the struct sockaddr according to the address family correctly. So, we > should do such sanity checking. This doesn't impair portability, it improves it. Since it is more permissive, yet still valid, it is compatible with the existing usage. > Furthermore, all of KAME delivered getnameinfo() including the version > shipped by ISC do the checking. Changing to only FreeBSD will cause > confusion. Not meaning to hold up glibc as a shining example, but this is how glibc behaves. FreeBSD would not be the first. In fact, this is needed for compatibility with systems that do honor the second parameter. Just because FreeBSD happens to have the sa_len field doesn't mean it should take precidence over the specified length. In fact for portability, the second parameter *must* be honored. Since sa_len doesn't exist on all systems, and isn't required to exist, it's value should arguably not be trusted as a portable app may have left it uninitialized. The getnameinfo() definition from RFC2553 and the FreeBSD man page does not require the sa_len field to be initialized prior to calling getnameinfo(). Since it's not required, it should not be relied upon. Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202280707.g1S77Rg27514>