[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: getnameinfo extra len checking
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 ...
Main Index |
Thread Index |