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