Re: getnameinfo extra len checking

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Mon Jun 21 2010 at 12:27:30 -0400, Thor Lancelot Simon wrote:
> On Mon, Jun 21, 2010 at 07:09:23PM +0300, Antti Kantee wrote:
> > > 
> > > I do not think so.  Why should we pander to broken code that doesn't
> > > set sa_len?
> > 
> > What is the purpose of sa_len?  The value is a function of sa_family,
> > is it not?
> 
> >From one point of view, yes.  But remember, this is crappy object
> "polymorphism" done in plain C.  You get to maintain a pile of macros
> that map every sa_family to its expected size and then violate the
> opacity of the sockaddr to check the family, figure out the expected
> size, and proceed accordingly.  Ugh.
> 
> Or you can use sa_len as I assume
> was expected, and treat opaque network addresses like opaque network
> addresses: your program doesn't need to know what kind of address nor
> how big that kind of address was intended to be; it's just "an address"
> of size sa_len, and you don't poke at any other members of the
> datastructure unless you actually _care_ what type it is.  I find that
> much cleaner.
> 
> Also, of course, checking sa_len against sa_family is an explicit
> abstraction violation which is genuinely useful for detecting that
> some part of your program is passing around corrupt sockaddrs.  Don't
> set sa_len, and you can't do that either.

Someone pointed out in private email it's used by our unix domain's
SUN_LEN().  I'm happy we don't have SIN_LEN() which subtracts the number
of zero bytes at the end of the IP address ;)

Aaaanyway, the whole issue is a little unfortunate given that SUSv3
doesn't require sa_len.  Code which expects it to be present and set to
a non-garbage value is not portable (or callable from standard-conformant
code).  So it's suckage either way ...