Message 88706 - Python tracker

➜

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	claymation
Recipients	Rhamphoryncus, benjamin.peterson, claymation, ezio.melotti, giampaolo.rodola, gregory.p.smith, gvanrossum, loewis, mattsmart, oubiwann, pitrou, pmoody, pnasrat, r.david.murray, shields
Date	2009年06月02日.02:03:07
SpamBayes Score	6.246872e-07
Marked as misclassified	No
Message-id	<8657ee3f0906011903o521ba1feo6a8d543b5f9ee130@mail.gmail.com>
In-reply-to	<8517e9350906011651o4290790bm26a08e0552fc3602@mail.gmail.com>

Content
On Mon, Jun 1, 2009 at 7:51 PM, pmoody <report@bugs.python.org> wrote: >> For an example of why 192.168.1.1 != 192.168.1.1/32, look no further >> than ifconfig: >> >> # ifconfig en0 192.168.1.1/32 >> # ifconfig en0 >> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 >> inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1 >> ... >> >> # ifconfig en0 192.168.1.1 >> # ifconfig en0 >> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 >> ... > > what this shows is that your copy of darwin defaults to a /24 > prefixlen; ipaddr assumes a /32 prefixlen. I don't see anything > particularly more intuitive with darwin, but in any event, it seems > to provide support for assuming a prefixlen when none is supplied. The example demonstrates one case where the strings '192.168.1.1' and '192.168.1.1/32' are not equivalent -- it wouldn't be hard to find other examples -- yet you seem to think that (a) this is Darwin-specific behavior, and that (b) this discrepancy is acceptable and does not constitute a design flaw. You're wrong on both fronts, since in fact all IP implementations understand classful addressing (as per RFC-791), not just Darwin, and your insistence on the equality of '192.168.1.1' and '192.168.1.1/32' means that your library is unusable in applications that pass ipaddr.IPv4 objects to ifconfig. Clay

Content

On Mon, Jun 1, 2009 at 7:51 PM, pmoody <report@bugs.python.org> wrote:
>> For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
>> than ifconfig:
>>
>> # ifconfig en0 192.168.1.1/32
>> # ifconfig en0
>> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>    inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1
>>    ...
>>
>> # ifconfig en0 192.168.1.1
>> # ifconfig en0
>> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>    inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>>    ...
>
> what this shows is that your copy of darwin defaults to a /24
> prefixlen; ipaddr assumes a /32 prefixlen. I don't see anything
> particularly *more* intuitive with darwin, but in any event, it seems
> to provide support for assuming a prefixlen when none is supplied.
The example demonstrates one case where the strings '192.168.1.1' and
'192.168.1.1/32' are not equivalent -- it wouldn't be hard to find
other examples -- yet you seem to think that (a) this is
Darwin-specific behavior, and that (b) this discrepancy is acceptable
and does not constitute a design flaw.
You're wrong on both fronts, since in fact all IP implementations
understand classful addressing (as per RFC-791), not just Darwin, and
your insistence on the equality of '192.168.1.1' and '192.168.1.1/32'
means that your library is unusable in applications that pass
ipaddr.IPv4 objects to ifconfig.
Clay

History
Date	User	Action	Args
2009年06月02日 02:03:10	claymation	set	recipients: + claymation, gvanrossum, loewis, gregory.p.smith, Rhamphoryncus, pitrou, giampaolo.rodola, benjamin.peterson, ezio.melotti, mattsmart, shields, pmoody, pnasrat, r.david.murray, oubiwann
2009年06月02日 02:03:08	claymation	link	issue3959 messages
2009年06月02日 02:03:07	claymation	create

homepage