BIND 10 #353: Move function 'check_port()' and 'check_addr()' to one library
BIND 10 Development
do-not-reply at isc.org
Fri Oct 15 16:11:35 UTC 2010
#353: Move function 'check_port()' and 'check_addr()' to one library
-------------------------------+--------------------------------------------
Reporter: zhanglikun | Owner: jinmei
Type: enhancement | Status: reviewing
Priority: major | Milestone:
Component: Unclassified | Resolution:
Keywords: | Sensitive: 0
Estimatedhours: 0.0 | Hours: 0
Billable: 1 | Totalhours: 0
Internal: 0 |
-------------------------------+--------------------------------------------
Changes (by vorner):
* owner: vorner => jinmei
Comment:
Replying to [comment:5 jinmei]:
> I've not seen anything obviously wrong, but one test failed for me:
> [...]
> This is strange. Maybe the inet_ntop() implementation on MacOS X (it's
BSD-derived as far as I know) is buggy. But we'll have to work around it.
I modified the function to guess first by a regular expression which
version of address it is. This saves one call to inet_ntop() that fails in
case of IPv6 address and should workaround about this problem as a
sideeffect. Could you run the tests once more and see if it really does? I
don't have MacOS.
> I also have following minor comments. I'd leave it to you whether and
how to address these points.
> - port_check()/addr_check() may not be a good name (and in that sense
check.py, too) because xxx_check() sounds like performing a check only and
it's not intuitive for it to return something
I changed it to _parse, which can be expected to complain if it is
invalid. Does it seem better?
> - it's not clear that IPAddr() raises socket.error against an invalid
input (unless you read the source code, and has knowledge that inet_pton()
raises that exception on failure). Please at least describe it in the
function description, and it's probably better to use a user-defined
specific exception.
Added and documented.
> - in check_test.py, you assume specific output of inet_ntop(), but as
far as I know it's implementation dependent (although we may expect a
"canonical form" with future implementation due to RFC5952).
I left it there. For one, I do not see any simple way to check it works.
For another, even if it is implementation dependent, the canonical form
(which I hope I put there) seems the only reasonable thing it could return
and I guess there's no system that would return something else. If there
is, the only thing that happens would be a false positive of the test (it
would fail even when it shouldn't), which is better than the other way
around. Would you mind if it is left there until we actually find a system
that returns something else?
--
Ticket URL: <http://bind10.isc.org/ticket/353#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list