sockaddr_storage

Hal Murray hmurray at megapathdsl.net
Sun Jan 22 14:03:02 UTC 2017


esr at thyrsus.com said:
> * Remove sockaddr_storage from our sockaddr_u union of sockaddr,
>   sockaddr_in, and sockaddr_in6, shaving about 100 bytes from its size
>   and substantially decreasing MRU entry memory consumption.

> I interpret this to mean that if we replaced that trailing sockaddr_u with
> sockaddr_storage, the size of an MRU entry would increase by about 100
> bytes. 

I probably went off on a wild goose chase.

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.

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.

----------

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


PS: HAVE_STRUCT_SOCKADDR_STORAGE isn't used by anything.


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list