I guess I don't follow here. The problem I have is that alloc_listener() allows "addr" to be NULL. Because of the lame implementation of strcmp() on NetWare, this causes a fault (The same thing would happen if sa->hostname where NULL also in this function). Allowing sa->hostname to be NULL by definition is fine. I just need to make sure that functions like strcmp() don't get called with a NULL value. Therefore, in this particular case, either "addr" needs to be initialized as it was before, or a check needs to be made before calling strcmp(). I just don't know which is the correct behavior given the refactoring of the code.
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 3:44:52 PM >>> --On Wednesday, August 13, 2003 15:14:40 -0600 Brad Nicholes <[EMAIL PROTECTED]> wrote: > This change causes a problem on NetWare. In the function > alloc_listener() before the change, the code did not allow the variable > addr to be NULL. In the changed code addr is allowed to be NULL which > means that the call to strcmp() after the call to > apr_sockaddr_port_get() causes NetWare to fault. Hmm. Now, I wonder how reliant we are upon the sockaddr_t having a non-NULL hostname field. Are we going to be allowed to leave it NULL? apr_sockaddr_info_get's documentation explicitly says it allows NULL inputs, but it doesn't say what the 'hostname' field will turn into. The IPv4 apr_sockaddr_info_get impl. just hardcodes sa->hostname to be "0.0.0.0", while the IPv6 branch (getaddrinfo impl) will leave it NULL. So, we may not reuse listeners on IPv4 right now (NULL gets translated into "0.0.0.0" and stored as that string in the sockaddr_t). I guess I'll prefer to have the hostname be what we passed into apr_sockaddr_info_get - that is the sa->hostname should be NULL even with IPv4 implementations. Then, we'll have to fix up the references to sa->hostname to allow for NULL values. Thoughts? Make sense? -- justin
