sockaddr_storage

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> It wasn't obvious from your message that getting rid of sockaddr_u involved 
> replacing it with sockaddr_storage.  Why would you want to use it?  It looks 
> like a step backwards in terms of type checking.

First, to eliminate a union from our source code. Second, to move from
a private type to a POSIX-standardized one that is likely to have a binding
in any language we move to.

> If the goal is to eliminate unions, you might be able to do it with your own 
> clone of sockaddr_storage that is only as long as you need it.
> 
> You could do it squeaky clean without unions by having both ipv4 and ipv6 
> fields in the same struct.  With only a bit of kludgery you could put the 
> ipv4 fields in ipv6 slots.

That's an interesting possibility...

> unions are a reasonably clean way of handling things like network packets.  
> How does Go do that?

With an opaque object structure. I don't know if the packet storage is
unioned internallly or not.  That can't be done in Go itself, but there's
a strange hack with interfaces

http://stackoverflow.com/questions/21553398/best-practice-for-unions-in-go

that can approximate it at the cost of some type safety.

> PS: HAVE_STRUCT_SOCKADDR_STORAGE isn't used by anything.

I'll remove it.  Anything thar can reduce the complexity of the waf recipe
makes me happy.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>