[anaconda root@sharpie /]# cat << __EOF__ | python - import ctypes ctypes.cdll.LoadLibrary("libnm-util.so.2") nm_utils = ctypes.CDLL("libnm-util.so.2") print nm_utils.nm_utils_ip4_prefix_to_netmask(24) __EOF__ -256 The expected result should be: 16777215
The code is buggy: you need to specify the type of the args and returntype (otherwise they defaults to c "int") >>> import ctypes >>> ctypes.cdll.LoadLibrary("libnm-util.so.2") <CDLL 'libnm-util.so.2', handle 100297b7a70 at 10029749290> >>> nm_utils = ctypes.CDLL("libnm-util.so.2") >>> print nm_utils.nm_utils_ip4_prefix_to_netmask(24) -256 but setting the argtypes and restype: >>> nm_utils.nm_utils_ip4_prefix_to_netmask.argtypes = [ctypes.c_uint32] >>> nm_utils.nm_utils_ip4_prefix_to_netmask.restype = ctypes.c_uint32 >>> print nm_utils.nm_utils_ip4_prefix_to_netmask(24) 4294967040 See http://docs.python.org/library/ctypes.html#specifying-the-required-argument-types-function-prototypes and http://docs.python.org/library/ctypes.html#return-types
...basing the types in comment 1 on the prototype here: http://developer.gnome.org/libnm-util/unstable/libnm-util-nm-utils.html#nm-utils-ip4-prefix-to-netmask which says: guint32 nm_utils_ip4_prefix_to_netmask (guint32 prefix); Note that ctypes can't check these types; if you get them wrong (or rely on the defaults) you're likely to get the wrong results (or a crash).
With the above mentioned fix, there is still a difference between ppc64 and x86_64 [anaconda root@sharpie /]# uname -a Linux sharpie.rchland.ibm.com 3.3.4-5.fc17.ppc64 #1 SMP Mon May 14 10:18:37 MST 2012 ppc64 ppc64 ppc64 GNU/Linux [anaconda root@sharpie /]# cat << __EOF__ | python - import ctypes ctypes.cdll.LoadLibrary("libnm-util.so.2") nm_utils = ctypes.CDLL("libnm-util.so.2") nm_utils.nm_utils_ip4_prefix_to_netmask.argtypes = [ctypes.c_uint32] nm_utils.nm_utils_ip4_prefix_to_netmask.restype = ctypes.c_uint32 val = nm_utils.nm_utils_ip4_prefix_to_netmask(24) print val print hex(val) __EOF__ 4294967040 0xffffff00L --- versus --- [root@hamzy-fedora17-build ~]# uname -a Linux hamzy-fedora17-build.localdomain 3.4.6-2.fc17.x86_64 #1 SMP Thu Jul 19 22:54:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [root@hamzy-fedora17-build ~]# cat << __EOF__ | python - import ctypes ctypes.cdll.LoadLibrary("libnm-util.so.2") nm_utils = ctypes.CDLL("libnm-util.so.2") nm_utils.nm_utils_ip4_prefix_to_netmask.argtypes = [ctypes.c_uint32] nm_utils.nm_utils_ip4_prefix_to_netmask.restype = ctypes.c_uint32 val = nm_utils.nm_utils_ip4_prefix_to_netmask(24) print val print hex(val) __EOF__ 16777215 0xffffffL
8<---8<--- /* vi bob.c && gcc -o bob `pkg-config --cflags --libs libnm-util` bob.c && ./bob */ #include <stdio.h> #include <nm-utils.h> int main (int argc, char *argv[]) { guint32 netmask; netmask = nm_utils_ip4_prefix_to_netmask (24); printf ("nm_utils_ip4_prefix_to_netmask (24) returns %d\n", netmask); return 0; } 8<---8<--- [root@hamzy-fedora17-build ~]# uname -a Linux hamzy-fedora17-build.localdomain 3.4.6-2.fc17.x86_64 #1 SMP Thu Jul 19 22:54:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [root@hamzy-fedora17-build ~]# vi bob.c && gcc -o bob `pkg-config --cflags --libs libnm-util` bob.c && ./bob nm_utils_ip4_prefix_to_netmask (24) returns 16777215 [root@bluebill ~]# uname -a Linux bluebill.rchland.ibm.com 3.3.4-5.fc17.ppc64 #1 SMP Mon May 14 10:18:37 MST 2012 ppc64 ppc64 ppc64 GNU/Linux [root@bluebill ~]# vi bob.c && gcc -o bob `pkg-config --cflags --libs libnm-util` bob.c && ./bob nm_utils_ip4_prefix_to_netmask (24) returns -256
The returned value is *unsigned*, and in this case, since the prefix netmask is so large in BE (255.255.255.0, = 42949767040), the high bit will be set, which means treating this as a plain integer will yield a negative number. And since the lower 8 bits are all 0, treating that as a signed number would match up with -256. Which means you want a %u there instead of a %d, right?
%u on both my iBook G3 and my x86_64 box gives me 4294967040 (G3) and 16777215 (x86_64). Also, note that the returned value from nm_utils_ip4_prefix_to_netmask() is network byte order; I've just clarified that in the code documentation too. It's supposed to be opposite of nm_utils_ip4_netmask_to_prefix() which takes a netmask in network byte order.
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=f19c33b56f7bd5fb20fb459b8eec3d8adb54d198
Also, API reference documentation is here: libnm-util: http://projects.gnome.org/NetworkManager/developers/libnm-util/09/ libnm-glib: http://projects.gnome.org/NetworkManager/developers/libnm-glib/09/ D-Bus API: http://projects.gnome.org/NetworkManager/developers/api/09/spec.html
So I'll close as "worksforme" for now; if that's not correct, please reopen. Thanks!
Created attachment 604365 [details] [PATCH] integer out of range for L format code
Reopening this as an anaconda bug.
Does the call to http://docs.python.org/library/socket.html#socket.inet_ntoa expect network byte order data?
(In reply to comment #12) > Does the call to http://docs.python.org/library/socket.html#socket.inet_ntoa > expect network byte order data? Python's socket.inet_ntoa (implemented in Modules/socketmodule.c) is a thin wrapper around glibc's inet_ntoa, and the manpage for that call says: "The inet_ntoa() function converts the Internet host address in, given in network byte order, to a string in IPv4 dotted-decimal notation." Hence I believe the answer is "network byte order".
You guys aren't still seeing this bug, are you?
No. I was hoping for clarification from Radek that the anaconda code won't have any further issues with network byte order information. But I can see that this won't happen. Closing this defect.