Joe Orton wrote: > On Thu, Nov 23, 2006 at 11:49:46AM -0600, William Rowe wrote: >> William A. Rowe, Jr. wrote: >>> It also appears that sockets.c in MANY cases just fails to initialize >>> (local|remote)_interface_unknown, unless I'm imagining things. >> Am I blinking insane or was this completely broken? > > You are setting some "->local_addr_unknown" in the patch which doesn't > exist. Even if this did /addr/interface/ then the patch doesn't look > obviously correct for the Unix code: apr_socket_bind() does not *unset* > ->local_interface_unknown so maybe assumes it was unset already. What > cases does this look broken for?
local_interface_unknown + local_port_unknown of course - thanks for that observation. SO - _bind() does the magic? Look again... I see a test for ip of 0,0,0,0[0,0,0,0,0,0,0,0,0,0,0,0] in apr_socket_accept() that would cause ld to resolve to local_port_unknown. In the case of apr_socket_bind, we set local_port_unknown appropriately. I dont' see a case where we flag local_interface_unknown prior to the apr_socket_accept(). Yet this doesn't happen by the alloc_socket() call. So where does your test case code get off calling apr_socket_addr_get when the local_interface_unknown is initialized to zero (known?) and the address is still ephemeral? > (The test_get_addr test was to check for a ->remote_addr_unknown > handling bug alone, FWIW: PR 32737) Understood. But the only thing an order of magnitude worse than missing test cases are test cases that are examples of incomprehensible code. It so happened that the failure of apr_socket_addr_get to detect the 'unknown' state of the interface resulted in 0.0.0.0 and it also so happens that on some platforms connect -will- bind to the ephemeral port. Not so on Windows. Three questions arise - * is the example faulty? * is the initialization of local_interface_unknown faulty? * is connect to ephemeral port somethign we should emulate?
