This code is an import from Bind-9.5.2-P2 merged with the old code from Inktomi days which was built to interface with an older version of the Bind code. Even back then it never had a real "owner", so I am sure that what you see as problems are problems and whatever fixes you come up with are most appreciated!
On Thu, Apr 28, 2011 at 4:46 PM, Alan M. Carroll < a...@network-geographics.com> wrote: > 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. > >From my quick scan of the web, it looks like this is to support the "sortlist" resolver config option which we don't use. > > 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. > Gack. Fortunately it isn't completely random: DNS.cc: h->m_res = &l_res; DNS.cc: memset(&l_res, 0, sizeof(l_res)); So we are closing socket 0? Kill it! > > 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? > That comment is probably from a long time ago when it was smaller. I have no idea why it would be padded out and it doesn't seem necessary. > > 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. > > Just out of curiosity you could take a look at the current Bind code, otherwise I think you know this code better than anyone now. Thanx, john
