I couldn't answer that question for sure. Taking a quick look through the Apache code and modules, I don't see anything. But that doesn't mean that some third party module doesn't depend on it. Do the recent changes, include allowing sa->hostname to be NULL where it didn't before?
From what I see in CVS now, there is only one implementation of apr_sockaddr_info_get() which is in unix/sockaddr.c. This calls one of two implementation of find_addresses() (whether you have getaddrinfo() or not). This is where sa->hostname is being defaulted to "0.0.0.0" ( in the non-getaddrinfo() implementation). It seems that both implementations should be sync'ed up to produce the same results. It appears that defaulting to "0.0.0.0" rather than NULL would be the safer thing to do. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Wednesday, August 13, 2003 4:18:19 PM >>> --On Wednesday, August 13, 2003 16:07:12 -0600 Brad Nicholes <[EMAIL PROTECTED]> wrote: > I guess I don't follow here. The problem I have is that > alloc_listener() allows "addr" to be NULL. Because of the lame Okay, let me try to restate the problem: - addr *may* be NULL when alloc_listener is invoked. Adding a NULL check before doing the strcmp would indeed fix this problem, but prevents listener reuse. - We *have* to pass NULL to apr_sockaddr_info_get so that getaddrname() can do the IPv6/IPv4 fail-over on its own (as it is supposed to do - httpd can't do the guessing correctly). - However, on *some* implementations (based on the code in CVS right now), the sa->hostname returned by apr_sockaddr_info_get may be NULL or "0.0.0.0" even if we passed NULL into apr_sockaddr_info_get. What we're trying to accomplish in this code fragment is to reuse old walkers that are already listening on the same port. So, this inconsistency means that an addr with a value of NULL *could* be equivalent to NULL or "0.0.0.0" (if the OS doesn't have IPv6). So, one of two things should happen: - We should allow NULLs in sa->hostname. We fix up the IPv4 implementation to not store "0.0.0.0" in the sa->hostname field, but NULL. - We don't allow NULLs in sa->hostname. Then, we need to take the 'name' returned by getaddrinfo() and store it. However, we would have to do this resolution before we can do the walking as NULL may resolve to (say): '0.0.0.0' or '::'. Only after calling apr_sockaddr_info_get would we know which it resolves to. My question was whether anything relies upon sa->hostname being a valid value? I don't think they should, but the sockaddr_t is part of the public conn_rec. -- justin
