I'm working on ink_resolver.h and ink_res_init.cc with regard to use 
sockaddr_storage and have come across what I find rather odd bits of code.

1) What is the sort_list about? It is loaded during initialization but 
apparently never referenced again, and the #define that enables it isn't set by 
configure.ac. Most significantly, it's not documented. So I am removing it 
entirely.

2) The nssocks array in __ink_res_state also seems vestigal but with the added 
element of risk. I can find no place it is initialized yet when the state is 
destroyed if any of the values are not -1 that file descriptor is closed. The 
effect would seem to be random closing file descriptors. I plan to remove that 
as well.

3) Is there some reason the __ink_res_state should be 512 bytes? It seems that 
the current structure is much larger than that. If that's not a requirement, 
why is the _ext struct in __ink_res_state in a padded union?

4) I don't see the point of the __ink_res_state_ext structure. It seems like it 
is vestigal from before the existence of ink_res_sockaddr_union. But that's now 
used in __ink_res_state (and I will be replacing it with sockaddr_storage 
anyway). I can find no use of the nsuffix or nsuffix2 members, which leaves the 
struct just another array of ink_res_sockaddr_union structs. I plan to simply 
discard the entire structure and use the nsaddr_list in __ink_res_state. This 
leaves the _ext struct with just two members which I think should be moved out 
to the main struct.

P.S. All that apparent concern about alignment, but there's a u_short id right 
in the middle of the struct.

Reply via email to