[Patches] [ python-Patches-658327 ] Add inet_pton and inet_ntop to socket

noreply@sourceforge.net noreply@sourceforge.net
Tue, 31 Dec 2002 08:52:27 -0800


Patches item #658327, was opened at 2002-12-24 16:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Add inet_pton and inet_ntop to socket

Initial Comment:
Patch is against current CVS and adds two socket module
functions, inet_pton and inet_ntop.  Both of these
should be available on all platforms (because of other
dependancies in the code) so I don't think portability
is a problem.  inet_ntop converts a packed IP address
to a human-readable '.' or ':' separated string
representation of the IP.  inet_pton performs the
reverse operation.

(Potential) problems: inet_pton sets errno to ENOSPC,
which may lead to a confusing error message.


----------------------------------------------------------------------

>Comment By: Jp Calderone (kuran)
Date: 2002-12-31 11:52

Message:
Logged In: YES 
user_id=366566

Doc, NEWS, and test_socket patch attached.  I didn't notice
any inet_aton/inet_ntoa tests in the module so I added a
couple for those as well (I excluded a test for
inet_ntoa('255.255.255.255') ;) Also included are a couple
IPv6 tests.  I'm not sure if these are appropriate, since
many systems may still lack the required support for them to
pass.  I'll leave it up to you to decide whether they should
be commented out or removed or whatever.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 08:17

Message:
Logged In: YES 
user_id=21627

I agree that such a change should be added. Neal, you have
given this patch more attention than I did - please check it
in when you consider it complete. I just like to point out
that it is missing documentation changes (libsocket.tex), a
NEWS entry, and a test case. kuran, please provide those as
a single patch file.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-30 19:11

Message:
Logged In: YES 
user_id=33168

ISTM that in socket_inet_ntop() you need to verify the size
of the packed value passed in.  If the user passes an empty
string, inet_ntop() could read beyond the buffer passed in,
potentially causing a core dump.

The checks could be something like this:

  if (af == AF_INET && len != sizeof(struct in_addr))
  else if (af == AF_INET6 && len != sizeof(struct in6_addr))

Do this make sense?

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-27 10:39

Message:
Logged In: YES 
user_id=366566

The use case I have for it at the moment is a DNS server
(Twisted.names).  inet_pton allows me to handle IPv6
addresses, so it allows me to support AAAA and A6 records. 
I believe an IPv6 capable socks proxy would find this useful
as well.  Basically, low level network stuff.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-27 05:23

Message:
Logged In: YES 
user_id=21627

What is the rationale for providing this functionality?

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-26 13:32

Message:
Logged In: YES 
user_id=366566

Ooops, I made two, and uploaded the wrong one >:O  Sorry. 
Dunno if it's still helpful, but here's the unified diff.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 13:10

Message:
Logged In: YES 
user_id=33168

Next time, please use context or unified diff.  -c or -u
option to cvs diff:  cvs diff -c ...

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-24 16:05

Message:
Logged In: YES 
user_id=366566

Sourceforge decided not to attach the file the first time...
 Here it is.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470