Hal Murray <hmur...@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> _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
