ctypes-users — Discussion forum for ctypes users

Re: [ctypes-users] NtQuerySystemInformation

[Diez B. R. <de...@we...>]

Have you tried defining the signature of NtQuerySystemInformation? It could be that arguments are being truncated.

Also, is that really a CDLL, not a WINDLL?

Cheers,

Diez

> On 28 Oct 2015, at 13:31, Cristian Badescu <cri...@gm...> wrote:
> 
> Hello,
> 
> I am trying to get handles information by using NtQuerySystemInformation but my code fails for some reason. I am using the following code to call NtQuerySystemInformation:
> 
> from ctypes import *
> from ctypes.util import *
> 
> class SYSTEM_HANDLE(Structure):
> 
>     _fields_ = [("ProcessId", c_ulong),
>                 ("ObjetTypeNumber", c_byte),
>                 ("Flags", c_byte),
>                 ("Handle", c_ushort),
>                 ("Object", c_void_p ),
>                 ("GrantedAccess", c_ulong)
>                 ]
> 
> class SYSTEM_HANDLE_INFORMATION(Structure):
> 
>     _fields_ = [("HandleCount", c_ulong),
>                 ("Handles", SYSTEM_HANDLE * 1)
>                 ]
> 
> handleInfoSize = 65536
> 
> SystemHandleInformation = 16
> 
> c_lib=CDLL(find_library("c"))
> malloc=c_lib.malloc
> malloc.restype=c_void_p
> handleInfo = malloc(handleInfoSize)
> 
> pHandleInfo = cast(handleInfo, POINTER(SYSTEM_HANDLE_INFORMATION))
> 
> retVal = cdll.ntdll.NtQuerySystemInformation(SystemHandleInformation, pHandleInfo, handleInfoSize, None)
> ------------------------------------------------------------------------------
> _______________________________________________
> ctypes-users mailing list
> cty...@li...
> https://lists.sourceforge.net/lists/listinfo/ctypes-users

[ctypes-users] NtQuerySystemInformation

[Cristian B. <cri...@gm...>]

Hello,

I am trying to get handles information by using NtQuerySystemInformation
but my code fails for some reason. I am using the following code to call
NtQuerySystemInformation:

from ctypes import *
from ctypes.util import *

class SYSTEM_HANDLE(Structure):

    _fields_ = [("ProcessId", c_ulong),
                ("ObjetTypeNumber", c_byte),
                ("Flags", c_byte),
                ("Handle", c_ushort),
                ("Object", c_void_p ),
                ("GrantedAccess", c_ulong)
                ]

class SYSTEM_HANDLE_INFORMATION(Structure):

    _fields_ = [("HandleCount", c_ulong),
                ("Handles", SYSTEM_HANDLE * 1)
                ]

handleInfoSize = 65536

SystemHandleInformation = 16

c_lib=CDLL(find_library("c"))
malloc=c_lib.malloc
malloc.restype=c_void_p
handleInfo = malloc(handleInfoSize)

pHandleInfo = cast(handleInfo, POINTER(SYSTEM_HANDLE_INFORMATION))

retVal = cdll.ntdll.NtQuerySystemInformation(SystemHandleInformation,
pHandleInfo, handleInfoSize, None)

[ctypes-users] Python ctypes program works on 3.2 but fails on 3.4

[TuX R. <tux...@gm...>]

Hello List

I suspect a bug in ctypes;
I asked the question below on stackoverflow:
http://stackoverflow.com/questions/32100067/python-ctypes-program-works-on-3-2-but-incompatiable-on-3-4

Any idea of why the same code would fail (return a blank string) on 3.4?

Thanks
TR

Re: [ctypes-users] contribute ctypeslib patch?

[Diez B. R. <de...@we...>]

I wouldn’t say it’s dead - it is just extremely mature, and in the aspect you seem to care about, superseded by CFFI.

However, as it’s in the mainline Python distro, you should file your patch as a bug in python’s own bug-tracker IMHO.

HTH,

Diez


> On 13 Aug 2015, at 07:19, Jan Wagner <jwa...@go...> wrote:
> 
> Hi list,
> 
> it seems this project is quite dead and I'm not sure how to
> contribute a feature fix (not even to
> https://pypi.python.org/pypi/ctypeslib/ <https://pypi.python.org/pypi/ctypeslib/>). Perhaps someone on the
> list is able to do it?
> 
> There is an issue in ctypeslib codegenerator.py that affects
> xml2py.py option "-r" for which usage says that "-r EXPRESSION 
> regular expression for symbols to include". The expression is
> actually never evaluated as a regular expression. Only exact name
> matches are selected. The below patch changes the behaviour to be
> consistent with the usage instructions (and makes -r behaviour more
> useful).
> 
> cheers,
> Jan
> 
> ---
> /usr/lib/pymodules/python2.5/ctypeslib/codegen/codegenerator.py    
> 2009-01-17 03:50:18.000000000 +0900
> +++ codegenerator.py    2015-04-08 18:34:06.000000000 +0900
> @@ -859,6 +859,12 @@
>                  if match and match.group() == i.name:
>                      todo.append(i)
>                      break
> +               # above selects only *exact* matches, now include
> partial/regexp name matches:
> +               match = s.search(i.name)
> +               if match:
> +                    todo.append(i)
> +                    break
> +
>      if symbols or expressions:
>          items = todo
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> ctypes-users mailing list
> cty...@li...
> https://lists.sourceforge.net/lists/listinfo/ctypes-users

[ctypes-users] contribute ctypeslib patch?

[Jan W. <jwa...@go...>]

Hi list,

it seems this project is quite dead and I'm not sure how to
contribute a feature fix (not even to
https://pypi.python.org/pypi/ctypeslib/). Perhaps someone on the
list is able to do it?

There is an issue in ctypeslib codegenerator.py that affects
xml2py.py option "-r" for which usage says that "-r EXPRESSION 
regular expression for symbols to include". The expression is
actually never evaluated as a regular expression. Only exact name
matches are selected. The below patch changes the behaviour to be
consistent with the usage instructions (and makes -r behaviour more
useful).

cheers,
Jan

---
/usr/lib/pymodules/python2.5/ctypeslib/codegen/codegenerator.py    
2009-01-17 03:50:18.000000000 +0900
+++ codegenerator.py    2015-04-08 18:34:06.000000000 +0900
@@ -859,6 +859,12 @@
                 if match and match.group() == i.name:
                     todo.append(i)
                     break
+               # above selects only *exact* matches, now include
partial/regexp name matches:
+               match = s.search(i.name)
+               if match:
+                    todo.append(i)
+                    break
+
     if symbols or expressions:
         items = todo

Re: [ctypes-users] Calling Objective C functions with ctypes

[Timothy W. G. <tim...@si...>]

Thanks! I preceded all of the string literals with 'b', apart from the 
initial 'find_library' calls, and the code worked fine.

Best regards,
Tim Grove

On 19/03/2015 16:46, eryksun wrote:
> On Thu, Mar 19, 2015 at 11:11 AM, Timothy W. Grove <tim...@si...> wrote:
>> pool = objc.objc_msgSend(pool, objc.sel_registerName('init'))
> Python 3 uses wide-character strings (i.e. wchar_t *). Try replacing
> all string literals with bytes literals, e.g.
> objc.sel_registerName(b'init').

Re: [ctypes-users] Calling Objective C functions with ctypes

[eryksun <er...@gm...>]

On Thu, Mar 19, 2015 at 11:11 AM, Timothy W. Grove <tim...@si...> wrote:
> pool = objc.objc_msgSend(pool, objc.sel_registerName('init'))

Python 3 uses wide-character strings (i.e. wchar_t *). Try replacing
all string literals with bytes literals, e.g.
objc.sel_registerName(b'init').

[ctypes-users] Calling Objective C functions with ctypes

[Timothy W. G. <tim...@si...>]

I have been trying to get the following code copied from another forum 
to work on my system (OSX 10.6, 10.8, Python 3.3 installed via 
MacPorts), and it just won't. It seems to be finding the 'AppKit' and 
'objc' libraries okay, but it is not getting the classes 
'NSSpeechSynthesizer' or 'NSAutoreleasePool', so 'count' ends up as '0' 
and everything falls over from there.

I did notice from the "print voiceNames" statement that this code must 
be pre-python 3, so are there any obvious changes needed to bring this 
up to date? Thanks for any help or suggestions.

Best regards,
Tim Grove

    [from
    http://stackoverflow.com/questions/1490039/calling-objective-c-functions-from-python/1490644#1490644]
    import ctypes
    import ctypes.util

    # Need to do this to load the NSSpeechSynthesizer class, which is in
    AppKit.framework
    appkit = ctypes.cdll.LoadLibrary(ctypes.util.find_library('AppKit'))
    objc = ctypes.cdll.LoadLibrary(ctypes.util.find_library('objc'))

    objc.objc_getClass.restype = ctypes.c_void_p
    objc.sel_registerName.restype = ctypes.c_void_p
    objc.objc_msgSend.restype = ctypes.c_void_p
    objc.objc_msgSend.argtypes = [ctypes.c_void_p, ctypes.c_void_p]

    # Without this, it will still work, but it'll leak memory
    NSAutoreleasePool = objc.objc_getClass('NSAutoreleasePool')
    pool = objc.objc_msgSend(NSAutoreleasePool,
    objc.sel_registerName('alloc'))
    pool = objc.objc_msgSend(pool, objc.sel_registerName('init'))

    NSSpeechSynthesizer = objc.objc_getClass('NSSpeechSynthesizer')
    availableVoices = objc.objc_msgSend(NSSpeechSynthesizer,
    objc.sel_registerName('availableVoices'))

    count = objc.objc_msgSend(availableVoices,
    objc.sel_registerName('count'))
    voiceNames = [
       ctypes.string_at(
         objc.objc_msgSend(
           objc.objc_msgSend(availableVoices,
    objc.sel_registerName('objectAtIndex:'), i),
           objc.sel_registerName('UTF8String')))
       for i in range(count)]
    print voiceNames

    objc.objc_msgSend(pool, objc.sel_registerName('release'))

Re: [ctypes-users] who can tell me the difference in ctypes.sizeof between Ironpython and python in using ctypes to create structure?

[eryksun <er...@gm...>]

On Tue, Mar 10, 2015 at 9:49 PM, 狂禅 <246...@qq...> wrote:
> recently i meet a problem in using Ironpython.
>     import ctypes as ct
>
>     class Data(ct.LittleEndianStructure):
>         _pack_      = 2
>         _fields_    = [
>
>             ('a',ct.c_ubyte),
>             ('b',ct.c_ubyte),
>             ('c',ct.c_ubyte),
>             ('d',ct.c_ushort),
>             ('e',ct.c_uint),
>             ('f',ct.c_ubyte),
>         ]
>     if __name__ == "__main__":
>         a = Data()
>         print ct.sizeof(a)
> as is show above.when i used this script running in python ,it prints 12.
> but when running in Ironpython ,it is 14.
> in fact ,i tried it in c like that:
>
>     #include<stdio.h>
>     void main()
>     {
>     #pragma pack(2)
>  struct{
>   unsigned char a;
>   unsigned char b;
>   unsigned char c;
>   unsigned short d;
>   unsigned int e;
>   unsigned char f;
>  }A;
>     #pragma pack()
>  printf("%d\n",sizeof(A));
>     }
> it is 12.
>
> can you tell me why it is and how i can crrect it in Ironpython???

Print the field reprs to see how it's defining the structure in terms
of offsets and sizes. Here's what I get in CPython on Windows:

    from ctypes import *

    class Data(LittleEndianStructure):
        _pack_ = 2
        _fields_ = (('a', c_ubyte),
                    ('b', c_ubyte),
                    ('c', c_ubyte),
                    ('d', c_ushort),
                    ('e', c_uint),
                    ('f', c_ubyte))

    >>> for field, dtype in Data._fields_:
    ...     print field, getattr(Data, field)
    ...
    a <Field type=c_ubyte, ofs=0, size=1>
    b <Field type=c_ubyte, ofs=1, size=1>
    c <Field type=c_ubyte, ofs=2, size=1>
    d <Field type=c_ushort, ofs=4, size=2>
    e <Field type=c_ulong, ofs=6, size=4>
    f <Field type=c_ubyte, ofs=10, size=1>

    >>> alignment(Data)
    2
    >>> sizeof(Data)
    12

The natural alignment is 4 bytes, which requires padding the structure
out to 16 bytes:

    class Data(LittleEndianStructure):
        _fields_ = (('a', c_ubyte),
                    ('b', c_ubyte),
                    ('c', c_ubyte),
                    ('d', c_ushort),
                    ('e', c_uint),
                    ('f', c_ubyte))

    >>> for field, dtype in Data._fields_:
    ...     print field, getattr(Data, field)
    ...
    a <Field type=c_ubyte, ofs=0, size=1>
    b <Field type=c_ubyte, ofs=1, size=1>
    c <Field type=c_ubyte, ofs=2, size=1>
    d <Field type=c_ushort, ofs=4, size=2>
    e <Field type=c_ulong, ofs=8, size=4>
    f <Field type=c_ubyte, ofs=12, size=1>

    >>> alignment(Data)
    4
    >>> sizeof(Data)
    16

HTH

[ctypes-users] who can tell me the difference in ctypes.sizeof between Ironpython and python in using ctypes to create structure?

[狂禅 <246...@qq...>]

recently i meet a problem in using Ironpython.
     import ctypes as ct
    
    class Data(ct.LittleEndianStructure):          
        _pack_      = 2
        _fields_    = [
            
            ('a',ct.c_ubyte),
            ('b',ct.c_ubyte),
            ('c',ct.c_ubyte),
            ('d',ct.c_ushort),
            ('e',ct.c_uint),
            ('f',ct.c_ubyte),             
        ]
    if __name__ == "__main__":
        a = Data()
        print ct.sizeof(a)
as is show above.when i used this script running in python ,it prints 12.
but when running in Ironpython ,it is 14.
 in fact ,i tried it in c like that:
 
    #include<stdio.h>
    void main()
    {
    #pragma pack(2)
 struct{
  unsigned char a;
  unsigned char b;
  unsigned char c;
  unsigned short d;
  unsigned int e;
  unsigned char f;
 }A;
    #pragma pack()
 printf("%d\n",sizeof(A));
    }
it is 12.
 
can you tell me why it is and how i can crrect it in Ironpython???

Re: [ctypes-users] Data_as

[eryksun <er...@gm...>]

On Tue, Dec 30, 2014 at 11:15 AM, West, Peter <pet...@uc...> wrote:
>
>    pointerArrayType = POINTER( c_uint16 ) * 2      # an array of pointers type length 2
>    pointers = pointerArrayType()                           # the actual array
....
>    print pointers[ 0 ]
>    print pointers[ 1 ]
>
> This prints
> <__main__.LP_c_ushort object at 0x00000000025132C8>
> <__main__.LP_c_ushort object at 0x00000000025132C8>
>
> This suggests that the data arrays for frame1 and frame2 are at the same location.

The repr shows the address of the Python object, not the pointer value.

    >>> x, y = pointers
    >>> print x
    <__main__.LP_c_ushort object at 0x7f10648378c0>
    >>> print y
    <__main__.LP_c_ushort object at 0x7f1064837c20>

The pointer's contents attribute returns a ctypes object that can be
passed to addressof.

    >>> from ctypes import addressof
    >>> pointers[0].contents
    c_ushort(0)
    >>> addressof(pointers[0].contents)
    43254640
    >>> addressof(pointers[1].contents)
    43274656

Note that pointers[0][0] wouldn't work. That converts the c_ushort to
a Python integer.

    >>> pointers[0][0]
    0
    >>> addressof(pointers[0][0])
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: invalid type

You could also cast to a void pointer.

    >>> from ctypes import cast, c_void_p
    >>> cast(pointers[0], c_void_p)
    c_void_p(43254640)
    >>> cast(pointers[1], c_void_p)
    c_void_p(43274656)

Or use the buffer protocol instead of cast.

    >>> c_void_p.from_buffer(pointers[0])
    c_void_p(43254640)
    >>> c_void_p.from_buffer(pointers[1])
    c_void_p(43274656)

Verify against the numpy array's ctypes attribute.

    >>> frame1.ctypes.data
    43254640
    >>> frame2.ctypes.data
    43274656

    >>> frame1.ctypes._as_parameter_
    c_void_p(43254640)
    >>> frame2.ctypes._as_parameter_
    c_void_p(43274656)

[ctypes-users] Data_as

[West, P. <pet...@uc...>]

Hi

I need to pass a DLL a pointer to an array of pointers to c arrays of unsigned 16 bit integers.

I started to do this using data_as(POINTER( type ) on sub-arrays.  This caused access violations. When I looked at what was in the pointer arrays I discovered that they all pointed to the same location.  After poking around a bit is seems that the problem is not to do with using sub-arrays as I expected but with the way in which I have approached the problem and I can't see what I'm doing wrong.  Here is a very simple example

from ctypes import POINTER, c_uint16
import numpy as  np

if __name__ == '__main__':

   pointerArrayType = POINTER( c_uint16 ) * 2      # an array of pointers type length 2
   pointers = pointerArrayType()                           # the actual array

   frame1 = np.zeros(( 100, 100 ), dtype = np.uint16, order = 'C' )   # Ensure C contiguous layout
   frame2 = np.zeros(( 100, 100 ), dtype = np.uint16, order = 'C' )

   pointers[ 0 ] = frame1.ctypes.data_as( POINTER( c_uint16 ))
   pointers[ 1 ] = frame2.ctypes.data_as( POINTER( c_uint16 ))

   print pointers[ 0 ]
   print pointers[ 1 ]

This prints 
<__main__.LP_c_ushort object at 0x00000000025132C8>
<__main__.LP_c_ushort object at 0x00000000025132C8>

This suggests that the data arrays for frame1 and frame2 are at the same location.  Clearly I've done something wrong but can't see what.  

Any help would be gratefully received.

Re: [ctypes-users] Array allocation

[Diez B. R. <de...@we...>]

Hi,

this is more a design than a technical question. The status quo is pretty clear: the DLL allocates, and then nobody deallocates - so you are leaking.

You can of course use Python to deallocate the data, by simply calling the free-function from the libc, or the equivalent on windows - which I do not know… If push comes to shove, implement myfree in your library with the same signature, and just make that call the OS' free.

But to me that is kinda crude. The best thing to would be to take advantage of Python's GC, because then you can completely forget about managing the memory yourself.

If your given example describes the nature of the problem sufficiently (meaning you *always* allocate a constant amount of data), you could make it a requirement to pass that amount of data in.

An alternative could be to return a struct, with the 20-byte-array as a member. This should have copy-semantics in C, so the returned Python-object+associated "raw" data will be deallocated by the GC.

When you are dynamic in your size-requirements, you can use API-designs as used by the OS, e.g. fread and similar: you pass not only in a pointer to a buffer, but *also* it's length, and return the amount of actually used bytes.

With this, you make it explicit in your interface design what the programmer has to do. Of course this allows for error-cases where you provide less data than required, and need to check for them. But that could be done once, in a Pythonic wrapping you provide.

HTH,

Diez


On Sep 24, 2014, at 6:15 AM, Koteswara Rao Ruvva <ru...@ya...> wrote:

> There was a mistake in my DLL and corrected. It works great. No changes were made to the code written by Eryksun. Wonderful.
> 
> BTW, how do we deallocate the memory (data) after its use. Is there a way to free that memory in Python code? Or should that be done in DLL? 
> 
> I would like to make this problem complete in the thread so that Python users can have clear picture from end to end.
> 
> From: Koteswara Rao Ruvva <ru...@ya...>
> To: eryksun <er...@gm...> 
> Cc: "cty...@li..." <cty...@li...> 
> Sent: Monday, September 22, 2014 10:27 PM
> Subject: Re: [ctypes-users] Array allocation
> 
> Great. Very well explained. 
> 
> For some reason, it is crashing with no erros in the console soon after mydll.getData(ctypes.byref(data)) is called. Reviewed the C code in the DLL carefully and found no issues.
> 
> I am on Windows 7 64Bit system with Python 2.7.7
> 
> Do you have any clue?
> 
> Thanks
> Kotesh
> 
> 
> From: eryksun <er...@gm...>
> To: Koteswara Rao Ruvva <ru...@ya...> 
> Cc: "cty...@li..." <cty...@li...> 
> Sent: Monday, September 22, 2014 5:51 PM
> Subject: Re: [ctypes-users] Array allocation
> 
> On Mon, Sep 22, 2014 at 12:34 AM, Koteswara Rao Ruvva <ru...@ya...> wrote:
> > I have the following getData function in a DLL that allocates memory and
> > fill its contents.
> >
> > extern "C" __declspec(dllexport) int getData(int *data) {
> >    int size = 20;
> >    data = (int*) malloc(size*sizeof(int));
> >
> >    for (int i = 0; i < size; i++) {
> >        data[i] = i*i;
> >    }
> >
> >    return size;
> > }
> >
> > I have the following Python code to call the getData function:
> >
> >        mydll = ctypes.cdll.LoadLibrary('MathFuncs.dll')
> >
> >        mydll.getData.argtypes = [ctypes.POINTER(ctypes.c_int)]
> >        mydll.getData.restype  = ctypes.c_int
> >
> >        data = ctypes.POINTER(ctypes.c_int)
> >        size = mydll.getData(ctypes.POINTER(data))
> >
> > When I execute, I get the following error:
> > ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: expected
> > LP_c_long instance instead of _ctypes.PyCPointerType
> >
> > I am not able to figure out the mistake. Could someone please correct me.
> 
> POINTER returns a pointer type that can be set in a function's
> argtypes. Subsequently calling the function requires that the
> corresponding argument is an instance of the type. So the immediate
> problem here is that `data` needs to be an instance of the pointer
> type.
> 
> That said, don't pass the pointer by value (initially NULL). Instead
> pass by reference in order to receive the address of the malloc'd
> buffer. For example:
> 
> // mathfuncs.cpp
> 
> #include <stdlib.h>
> 
> // The data paramater has to be a pointer to a pointer, i.e.
> // an int **. The address of the malloc'd buffer gets stored
> // to the caller's pointer, i.e. *data.
> 
> extern "C" __declspec(dllexport) int getData(int **data) {
>     int size = 20;
>     int *arr = (int *)malloc(size * sizeof(int));
>     for (int i = 0; i < size; i++)
>         arr[i] = i*i;
>     *data = arr;
>     return size;
> }
> 
> 
> # test_mathfuncs.py
> 
> import ctypes
> 
> # Use CDLL instead of cdll.LoadLibrary. Windows appends the .dll
> # extension for you.
> mydll = ctypes.CDLL('mathfuncs')
> 
> c_int_p = ctypes.POINTER(ctypes.c_int)
> c_int_pp = ctypes.POINTER(c_int_p)
> 
> mydll.getData.argtypes = [c_int_pp]
> mydll.getData.restype  = ctypes.c_int
> 
> # Instantiate an int * pointer.
> data = c_int_p()
> 
> # Use byref to pass the address of the pointer.
> size = mydll.getData(ctypes.byref(data))
> 
> print("data.contents is", data.contents)
> # data.contents is c_long(0)
> 
> print("size ==", size)
> 
> # size == 20
> 
> 
> print("data[size-1] ==", data[size-1])
> # data[size-1] == 361
> 
> print("data[:3] ==", data[:3])
> # data[:3] == [0, 1, 4]
> 
> # Casting the result to an array requires
> # a pointer cast to int (*)[size]; then
> # a pointer dereference.
> # typedefs
> array_t = ctypes.c_int * size
> array_t_p = ctypes.POINTER(array_t)
> # pointer cast
> p_data_array = ctypes.cast(data, array_t_p)
> # pointer dereference
> data_array = p_data_array.contents
> 
> # array_t is an aggregate type consisting of 20 elements
> # that are each 4 bytes.
> 
> print("sizeof(data_array) ==",  ctypes.sizeof(data_array))
> print("len(data_array) ==", len(data_array))
> # sizeof(data_array) == 80
> # len(data_array) == 20
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> ctypes-users mailing list
> cty...@li...
> https://lists.sourceforge.net/lists/listinfo/ctypes-users

Re: [ctypes-users] Array allocation

[Koteswara R. R. <ru...@ya...>]

There was a mistake in my DLL and corrected. It works great. No changes were made to the code written by Eryksun. Wonderful.

BTW, how do we deallocate the memory (data) after its use. Is there a way to free that memory in Python code? Or should that be done in DLL? 

I would like to make this problem complete in the thread so that Python users can have clear picture from end to end.


________________________________
 From: Koteswara Rao Ruvva <ru...@ya...>
To: eryksun <er...@gm...> 
Cc: "cty...@li..." <cty...@li...> 
Sent: Monday, September 22, 2014 10:27 PM
Subject: Re: [ctypes-users] Array allocation
 


Great. Very well explained. 

For some reason, it is crashing with no erros in the console soon after mydll.getData(ctypes.byref(data)) is called. Reviewed the C code in the DLL carefully and found no issues.

I am on Windows 7 64Bit system with Python 2.7.7

Do you have any clue?

Thanks
Kotesh



________________________________
 From: eryksun <er...@gm...>
To: Koteswara Rao Ruvva <ru...@ya...> 
Cc: "cty...@li..." <cty...@li...> 
Sent: Monday, September 22, 2014 5:51 PM
Subject: Re: [ctypes-users] Array allocation
 

On Mon, Sep 22, 2014 at 12:34 AM, Koteswara Rao Ruvva <ru...@ya...> wrote:
> I have the following getData function in a DLL that allocates memory and
> fill its contents.
>
> extern "C" __declspec(dllexport) int getData(int *data) {
>     int size = 20;
>     data = (int*) malloc(size*sizeof(int));
>
>     for (int i = 0; i < size; i++) {
> 
        data[i] = i*i;
>     }
>
>     return size;
> }
>
> I have the following Python code to call the getData function:
>
>        mydll = ctypes.cdll.LoadLibrary('MathFuncs.dll')
>
>        mydll.getData.argtypes = [ctypes.POINTER(ctypes.c_int)]
>        mydll.getData.restype  = ctypes.c_int
>
>        data = ctypes.POINTER(ctypes.c_int)
>        size = mydll.getData(ctypes.POINTER(data))
>
> When I execute, I get the following error:
> ctypes.ArgumentError: argument 1: <type
 'exceptions.TypeError'>: expected
> LP_c_long instance instead of
 _ctypes.PyCPointerType
>
> I am not able to figure out the mistake. Could someone please correct me.

POINTER returns a pointer type that can be set in a function's
argtypes. Subsequently calling the function requires that the
corresponding argument is an instance of the type. So the immediate
problem here is that `data` needs to be an instance of the pointer
type.

That said, don't pass the pointer by value (initially NULL). Instead
pass by reference in order to receive the address of the malloc'd
buffer. For example:

// mathfuncs.cpp

#include <stdlib.h>

// The data paramater has to be a pointer to a pointer, i.e.
// an int **. The address
 of the malloc'd buffer gets stored
// to the caller's pointer, i.e. *data.

extern "C" __declspec(dllexport) int getData(int **data) {
    int size = 20;
    int *arr = (int *)malloc(size * sizeof(int));
    for (int i = 0; i < size; i++)
        arr[i] = i*i;
    *data = arr;
    return size;
}


# test_mathfuncs.py

import ctypes

# Use CDLL instead of cdll.LoadLibrary. Windows appends the .dll
# extension for you.
mydll = ctypes.CDLL('mathfuncs')

c_int_p = ctypes.POINTER(ctypes.c_int)
c_int_pp = ctypes.POINTER(c_int_p)

mydll.getData.argtypes = [c_int_pp]
mydll.getData.restype  = ctypes.c_int

# Instantiate an int * pointer.
data = c_int_p()

# Use byref to pass the address of the pointer.
size = mydll.getData(ctypes.byref(data))

print("data.contents is", data.contents)
# data.contents is c_long(0)

print("size ==", size)

# size == 20

print("data[size-1] ==", data[size-1])
# data[size-1] == 361

print("data[:3] ==", data[:3])
# data[:3] == [0, 1, 4]

# Casting the result to an array requires
# a pointer cast to
 int (*)[size]; then
# a pointer dereference.
# typedefs
array_t = ctypes.c_int * size
array_t_p = ctypes.POINTER(array_t)
# pointer cast
p_data_array = ctypes.cast(data, array_t_p)
# pointer dereference
data_array = p_data_array.contents

# array_t is an aggregate type consisting of 20 elements
# that are each 4 bytes.

print("sizeof(data_array) ==",  ctypes.sizeof(data_array))
print("len(data_array) ==", len(data_array))
# sizeof(data_array) == 80
# len(data_array) == 20

Re: [ctypes-users] Array allocation

[Koteswara R. R. <ru...@ya...>]

Great. Very well explained. 

For some reason, it is crashing with no erros in the console soon after mydll.getData(ctypes.byref(data)) is called. Reviewed the C code in the DLL carefully and found no issues.

I am on Windows 7 64Bit system with Python 2.7.7

Do you have any clue?

Thanks
Kotesh



________________________________
 From: eryksun <er...@gm...>
To: Koteswara Rao Ruvva <ru...@ya...> 
Cc: "cty...@li..." <cty...@li...> 
Sent: Monday, September 22, 2014 5:51 PM
Subject: Re: [ctypes-users] Array allocation
 

On Mon, Sep 22, 2014 at 12:34 AM, Koteswara Rao Ruvva <ru...@ya...> wrote:
> I have the following getData function in a DLL that allocates memory and
> fill its contents.
>
> extern "C" __declspec(dllexport) int getData(int *data) {
>     int size = 20;
>     data = (int*) malloc(size*sizeof(int));
>
>     for (int i = 0; i < size; i++) {
>         data[i] = i*i;
>     }
>
>     return size;
> }
>
> I have the following Python code to call the getData function:
>
>        mydll = ctypes.cdll.LoadLibrary('MathFuncs.dll')
>
>        mydll.getData.argtypes = [ctypes.POINTER(ctypes.c_int)]
>        mydll.getData.restype  = ctypes.c_int
>
>        data = ctypes.POINTER(ctypes.c_int)
>        size = mydll.getData(ctypes.POINTER(data))
>
> When I execute, I get the following error:
> ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: expected
> LP_c_long instance instead of
 _ctypes.PyCPointerType
>
> I am not able to figure out the mistake. Could someone please correct me.

POINTER returns a pointer type that can be set in a function's
argtypes. Subsequently calling the function requires that the
corresponding argument is an instance of the type. So the immediate
problem here is that `data` needs to be an instance of the pointer
type.

That said, don't pass the pointer by value (initially NULL). Instead
pass by reference in order to receive the address of the malloc'd
buffer. For example:

// mathfuncs.cpp

#include <stdlib.h>

// The data paramater has to be a pointer to a pointer, i.e.
// an int **. The address
 of the malloc'd buffer gets stored
// to the caller's pointer, i.e. *data.

extern "C" __declspec(dllexport) int getData(int **data) {
    int size = 20;
    int *arr = (int *)malloc(size * sizeof(int));
    for (int i = 0; i < size; i++)
        arr[i] = i*i;
    *data = arr;
    return size;
}


# test_mathfuncs.py

import ctypes

# Use CDLL instead of cdll.LoadLibrary. Windows appends the .dll
# extension for you.
mydll = ctypes.CDLL('mathfuncs')

c_int_p = ctypes.POINTER(ctypes.c_int)
c_int_pp = ctypes.POINTER(c_int_p)

mydll.getData.argtypes = [c_int_pp]
mydll.getData.restype  = ctypes.c_int

# Instantiate an int * pointer.
data = c_int_p()

# Use byref to pass the address of the pointer.
size = mydll.getData(ctypes.byref(data))

print("data.contents is", data.contents)
# data.contents is c_long(0)

print("size ==", size)

# size == 20

print("data[size-1] ==", data[size-1])
# data[size-1] == 361

print("data[:3] ==", data[:3])
# data[:3] == [0, 1, 4]

# Casting the result to an array requires
# a pointer cast to int (*)[size]; then
# a pointer dereference.
# typedefs
array_t = ctypes.c_int * size
array_t_p = ctypes.POINTER(array_t)
# pointer cast
p_data_array = ctypes.cast(data, array_t_p)
# pointer dereference
data_array = p_data_array.contents

# array_t is an aggregate type consisting of 20 elements
# that are each 4 bytes.

print("sizeof(data_array) ==",  ctypes.sizeof(data_array))
print("len(data_array) ==", len(data_array))
# sizeof(data_array) == 80
# len(data_array) == 20

Re: [ctypes-users] Array allocation

[eryksun <er...@gm...>]

On Mon, Sep 22, 2014 at 12:34 AM, Koteswara Rao Ruvva <ru...@ya...> wrote:
> I have the following getData function in a DLL that allocates memory and
> fill its contents.
>
> extern "C" __declspec(dllexport) int getData(int *data) {
>     int size = 20;
>     data = (int*) malloc(size*sizeof(int));
>
>     for (int i = 0; i < size; i++) {
>         data[i] = i*i;
>     }
>
>     return size;
> }
>
> I have the following Python code to call the getData function:
>
>        mydll = ctypes.cdll.LoadLibrary('MathFuncs.dll')
>
>        mydll.getData.argtypes = [ctypes.POINTER(ctypes.c_int)]
>        mydll.getData.restype  = ctypes.c_int
>
>        data = ctypes.POINTER(ctypes.c_int)
>        size = mydll.getData(ctypes.POINTER(data))
>
> When I execute, I get the following error:
> ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: expected
> LP_c_long instance instead of _ctypes.PyCPointerType
>
> I am not able to figure out the mistake. Could someone please correct me.

POINTER returns a pointer type that can be set in a function's
argtypes. Subsequently calling the function requires that the
corresponding argument is an instance of the type. So the immediate
problem here is that `data` needs to be an instance of the pointer
type.

That said, don't pass the pointer by value (initially NULL). Instead
pass by reference in order to receive the address of the malloc'd
buffer. For example:

// mathfuncs.cpp

#include <stdlib.h>

// The data paramater has to be a pointer to a pointer, i.e.
// an int **. The address of the malloc'd buffer gets stored
// to the caller's pointer, i.e. *data.

extern "C" __declspec(dllexport) int getData(int **data) {
    int size = 20;
    int *arr = (int *)malloc(size * sizeof(int));
    for (int i = 0; i < size; i++)
        arr[i] = i*i;
    *data = arr;
    return size;
}


# test_mathfuncs.py

import ctypes

# Use CDLL instead of cdll.LoadLibrary. Windows appends the .dll
# extension for you.
mydll = ctypes.CDLL('mathfuncs')

c_int_p = ctypes.POINTER(ctypes.c_int)
c_int_pp = ctypes.POINTER(c_int_p)

mydll.getData.argtypes = [c_int_pp]
mydll.getData.restype  = ctypes.c_int

# Instantiate an int * pointer.
data = c_int_p()

# Use byref to pass the address of the pointer.
size = mydll.getData(ctypes.byref(data))

print("data.contents is", data.contents)
# data.contents is c_long(0)

print("size ==", size)
# size == 20

print("data[size-1] ==", data[size-1])
# data[size-1] == 361

print("data[:3] ==", data[:3])
# data[:3] == [0, 1, 4]

# Casting the result to an array requires
# a pointer cast to int (*)[size]; then
# a pointer dereference.
# typedefs
array_t = ctypes.c_int * size
array_t_p = ctypes.POINTER(array_t)
# pointer cast
p_data_array = ctypes.cast(data, array_t_p)
# pointer dereference
data_array = p_data_array.contents

# array_t is an aggregate type consisting of 20 elements
# that are each 4 bytes.

print("sizeof(data_array) ==",  ctypes.sizeof(data_array))
print("len(data_array) ==", len(data_array))
# sizeof(data_array) == 80
# len(data_array) == 20

[ctypes-users] Array allocation

[Koteswara R. R. <ru...@ya...>]

Hello All,

I have the following getData function in a DLL that allocates memory and fill its contents.

extern "C" __declspec(dllexport) int getData(int *data) {
int size = 20;
               data = (int*) malloc(size*sizeof(int)); 

for (int i = 0; i < size; i++) {
data[i] = i*i;
}

return size;
}


I have the following Python code to call the getData function:

       mydll = ctypes.cdll.LoadLibrary('MathFuncs.dll')

       mydll.getData.argtypes = [ctypes.POINTER(ctypes.c_int)]
       mydll.getData.restype  = ctypes.c_int

       data = ctypes.POINTER(ctypes.c_int)

       size = mydll.getData(ctypes.POINTER(data))


When I execute, I get the following error:
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: expected LP_c_long instance instead of _ctypes.PyCPointerType

I am not able to figure out the mistake. Could someone please correct me.

Thanks
Kotesh

Re: [ctypes-users] ctypes.windll.kernel32.GetProcAddress returns address of 0

[Jason M. <jm...@ya...>]

I found the DirectX type library dx7vb.dll in the DirectX 7 SDK. 
(Also, dx7vb.dll from the DirectX 8 SDK can be downloaded here: http://www.thevbzone.com/d_DLL.htm ) I used comtypes' GetModule to generate the interface code. I haven't yet experimented further though.

Jason


________________________________
 From: RayS <ra...@bl...>
To: Thomas Heller <th...@ct...>; cty...@li... 
Sent: Monday, June 16, 2014 8:48 AM
Subject: Re: [ctypes-users] ctypes.windll.kernel32.GetProcAddress returns address of 0
 


BTW, there is a complete lack of DirectDraw
examples out there, especially using Python. If someone has links to such
I'd appreciate it, especially those for 3D surfaces. (We're slowly trying
to build an accelerated wxPyPlot-like widget that uses OpenGL/DirectDraw
- and I mean slowly...)

- Ray 

At 12:17 AM 6/16/2014, Thomas Heller wrote:

Am 14.06.2014 14:41, schrieb
Jason Marshall:
>> Hello ctypes-users,
>>
>> I am a novice at ctypes and C. I am trying to get the addresses of
some
>> methods in ddraw.dll (obsolete, I know) so that I may use them
with
>> pygame. When I run the script below to get the methods'
addresses,
>> ctypes.windll.kernel32.GetProcAddress gives me addresses of 0. Can
you
>> see something that I'm doing wrong?
>
>The Microsoft documentation is misleading; GetMonitorFrequeny and
>GetScanLine are not *functions* exposed by the directdraw library.
>Instead they are methods exposed of the IDirectDraw COM object.
>
>You cannot access this stuff with stock ctypes.  If you are
able
>to find a typelibary for directdraw then maybe you can do it with
>comtypes.
>
>Thomas
>
>
>------------------------------------------------------------------------------
>HPCC Systems Open Source Big Data Platform from LexisNexis Risk
Solutions
>Find What Matters Most in Your Big Data with HPCC Systems
>Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>Leverages Graph Analysis for Fast Processing & Easy Data
Exploration
>http://p.sf.net/sfu/hpccsystems
>_______________________________________________
>ctypes-users mailing list
>cty...@li...
>https://lists.sourceforge.net/lists/listinfo/ctypes-users

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems

_______________________________________________
ctypes-users mailing list
cty...@li...
https://lists.sourceforge.net/lists/listinfo/ctypes-users

Re: [ctypes-users] ctypes.windll.kernel32.GetProcAddress returns address of 0

[RayS <ra...@bl...>]

BTW, there is a complete lack of DirectDraw examples out there, 
especially using Python. If someone has links to such I'd appreciate 
it, especially those for 3D surfaces. (We're slowly trying to build 
an accelerated wxPyPlot-like widget that uses OpenGL/DirectDraw - and 
I mean slowly...)

- Ray

At 12:17 AM 6/16/2014, Thomas Heller wrote:
>Am 14.06.2014 14:41, schrieb Jason Marshall:
> > Hello ctypes-users,
> >
> > I am a novice at ctypes and C. I am trying to get the addresses of some
> > methods in ddraw.dll (obsolete, I know) so that I may use them with
> > pygame. When I run the script below to get the methods' addresses,
> > ctypes.windll.kernel32.GetProcAddress gives me addresses of 0. Can you
> > see something that I'm doing wrong?
>
>The Microsoft documentation is misleading; GetMonitorFrequeny and
>GetScanLine are not *functions* exposed by the directdraw library.
>Instead they are methods exposed of the IDirectDraw COM object.
>
>You cannot access this stuff with stock ctypes.  If you are able
>to find a typelibary for directdraw then maybe you can do it with
>comtypes.
>
>Thomas
>
>
>------------------------------------------------------------------------------
>HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>Find What Matters Most in Your Big Data with HPCC Systems
>Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>http://p.sf.net/sfu/hpccsystems
>_______________________________________________
>ctypes-users mailing list
>cty...@li...
>https://lists.sourceforge.net/lists/listinfo/ctypes-users

Re: [ctypes-users] ctypes.windll.kernel32.GetProcAddress returns address of 0

[Thomas H. <th...@ct...>]

Am 14.06.2014 14:41, schrieb Jason Marshall:
> Hello ctypes-users,
>
> I am a novice at ctypes and C. I am trying to get the addresses of some
> methods in ddraw.dll (obsolete, I know) so that I may use them with
> pygame. When I run the script below to get the methods' addresses,
> ctypes.windll.kernel32.GetProcAddress gives me addresses of 0. Can you
> see something that I'm doing wrong?

The Microsoft documentation is misleading; GetMonitorFrequeny and
GetScanLine are not *functions* exposed by the directdraw library.
Instead they are methods exposed of the IDirectDraw COM object.

You cannot access this stuff with stock ctypes.  If you are able
to find a typelibary for directdraw then maybe you can do it with
comtypes.

Thomas

[ctypes-users] ctypes.windll.kernel32.GetProcAddress returns address of 0

[Jason M. <jm...@ya...>]

Hello ctypes-users,


I am a novice at ctypes and C. I am trying to get the addresses of some methods in ddraw.dll (obsolete, I know) so that I may use them with pygame. When I run the script below to get the methods' addresses, ctypes.windll.kernel32.GetProcAddress gives me addresses of 0. Can you see something that I'm doing wrong?


I have tried this in Python 2.7 (32-bit) under Win 7 (64-bit) and Python 2.5 (32-bit) under Win XP (32-bit). I got the same result in both environments.


Thanks,
Jason


# coding: cp1252
# What I am trying to do:
#   http://www.nerdblog.com/2010/04/fun-vertical-sync-hack.html
#
# DirectDrawCreate function
#   http://msdn.microsoft.com/en-us/library/windows/desktop/gg426116%28v=vs.85%29.aspx
# IDirectDraw7::GetMonitorFrequency method
#   http://msdn.microsoft.com/en-us/library/windows/desktop/gg426148%28v=vs.85%29.aspx
# IDirectDraw7::GetScanLine method
#   http://msdn.microsoft.com/en-us/library/windows/desktop/gg426149%28v=vs.85%29.aspx
# 
# DirectX headers
#   http://www.steve-oh.com/blog/index.php/directx-70a-sdk-download/
#
# scary GUID structure
#   https://code.google.com/p/pyglet/source/browse/pyglet/com.py
# scary pointer to a pointer
#   http://stackoverflow.com/questions/8638942/python-ctypes-pointer-to-pointer-to-structure

import ctypes
from ctypes import POINTER, WINFUNCTYPE, byref, c_int, c_char_p, c_void_p, windll, wintypes

DD_OK = 0

# Load DirectDraw DLL
ddraw_dll = windll.LoadLibrary("ddraw")

# Initialize DirectDraw with DirectDrawCreate
class GUID(ctypes.Structure):
    _fields_ = [
        ('Data1', ctypes.c_ulong),
        ('Data2', ctypes.c_ushort),
        ('Data3',
 ctypes.c_ushort),
        ('Data4', ctypes.c_ubyte * 8)
    ]


    def __init__(self, l=0x6C14DB80, w1=0xA733, w2=0x11CE, b1=0xA5, b2=0x21, b3=0x00, b4=0x20, b5=0xAF, b6=0x0B, b7=0xE5, b8=0x60): # IID_IDirectDraw
        self.Data1 = l
        self.Data2 = w1
        self.Data3 = w2
        self.Data4[:] = (b1, b2, b3, b4, b5, b6, b7, b8)

    def __repr__(self):
        b1, b2, b3, b4, b5, b6, b7, b8 = self.Data4
        return 'GUID(%x, %x, %x, %x, %x, %x, %x, %x, %x, %x, %x)' % (
            self.Data1, self.Data2, self.Data3, b1, b2, b3, b4, b5, b6, b7, b8)

DirectDrawCreate = ddraw_dll.DirectDrawCreate
DirectDrawCreate.argtypes = [c_void_p,
 POINTER(POINTER(GUID)), c_void_p]
control = POINTER(GUID)()
result = DirectDrawCreate(None, byref(control), None)

print "DirectDrawCreate result (0 is DD_OK):", result
assert result == DD_OK, "DirectDraw did not initialize"

# Get GetMonitorFrequency function's address
windll.kernel32.GetProcAddress.argtypes = [c_void_p, c_char_p]
GetMonitorFrequency_addr = windll.kernel32.GetProcAddress(ddraw_dll._handle, "GetMonitorFrequency")
print "GetMonitorFrequency_addr", hex(GetMonitorFrequency_addr)

# Get GetScanLine function's address
GetScanLine_addr = windll.kernel32.GetProcAddress(ddraw_dll._handle, "GetScanLine")
print "GetScanLine_addr", hex(GetScanLine_addr)

Re: [ctypes-users] Can't create small bitfields

[Rob G. <rg...@hi...>]

On Tue, 15 Apr 2014 22:54:45 -0400
eryksun <er...@gm...> wrote:

> On Tue, Apr 15, 2014 at 8:01 PM, Rob Gaddi
> <rg...@hi...> wrote:
> > the smallest Structure I can get is 4 bytes.  Any ideas on what I'm
> > doing wrong?
> >
> > from __future__ import print_function
> > from ctypes import *
> >
> > class Struct(Structure):
> >     _pack_ = 1
> >
> > Struct._fields_ = [
> >         ('low', c_uint, 4),
> >         ('high', c_uint, 4),
> >     ]
> 
> You're using c_uint as the storage unit size. Instead use c_ubyte:
> 
>     from ctypes import *
> 
>     class Struct(Structure):
>         _fields_ = [('low', c_ubyte, 4),
>                     ('high', c_ubyte, 4)]
> 
>     x = Struct(low=7, high=15)
> 
> 
>     >>> sizeof(x)
>     1
>     >>> (x.high << 4) + x.low
>     247
>     >>> list(bytes(x))
>     [247]

Eryksun --

Thanks, that fixed the immediate problem.  Though it did help point out
the degree to which I really don't understand what makes Structure
bitfields work.  For instance, I would have expected that if I took the
above, and made each field a c_uint8 of size 6, that I'd get a two byte
structure with 'high' spanning the byte boundary.  But in order to get
that, I need to use c_uint16 as the underlying type instead; c_uint8s
give me two bits of padding between.

So, is the underlying type size supposed to match the size of the
overall structure you're trying to fill?  Is there any simple reference
on this, or is it just a matter of sitting down with a solid 4 hours to
burn to read the _ctypes code?

Thanks again,
Rob

-- 
Rob Gaddi, Highland Technology
18 Otis St.
San Francisco, CA 94103
415-551-1700

Re: [ctypes-users] Can't create small bitfields

[eryksun <er...@gm...>]

On Tue, Apr 15, 2014 at 8:01 PM, Rob Gaddi
<rg...@hi...> wrote:
> the smallest Structure I can get is 4 bytes.  Any ideas on what I'm
> doing wrong?
>
> from __future__ import print_function
> from ctypes import *
>
> class Struct(Structure):
>     _pack_ = 1
>
> Struct._fields_ = [
>         ('low', c_uint, 4),
>         ('high', c_uint, 4),
>     ]

You're using c_uint as the storage unit size. Instead use c_ubyte:

    from ctypes import *

    class Struct(Structure):
        _fields_ = [('low', c_ubyte, 4),
                    ('high', c_ubyte, 4)]

    x = Struct(low=7, high=15)


    >>> sizeof(x)
    1
    >>> (x.high << 4) + x.low
    247
    >>> list(bytes(x))
    [247]

[ctypes-users] Can't create small bitfields

[Rob G. <rg...@hi...>]

I'm trying to build up bitfields that are smaller than the word size of
the machine, only 1 or 2 bytes.  Unfortunately, the smallest Structure
I can get is 4 bytes.  Any ideas on what I'm doing wrong?  OS is
x86_64 Ubuntu, Python is 2.7.4 or 3.3.1 with equal results.  Sample code
below.

---

from __future__ import print_function
from ctypes import *

class Struct(Structure):
    _pack_ = 1
    
Struct._fields_ = [
        ('low', c_uint, 4),
        ('high', c_uint, 4),
    ]
    
x = Struct(low = 1, high = 2)
    
print('Structure Size:', sizeof(Struct))
print('Instance Size:', sizeof(x))
print('Structure Fields:', Struct.low, Struct.high)
print('Instance Fields:', x.low, x.high)

arr = (c_uint8 * sizeof(x)).from_buffer(x)
print('Bytes:', ','.join('{0:02X}'.format(b) for b in arr))

---

$python_vme_mods$ python test_bitfield.py 
Structure Size: 4
Instance Size: 4
Structure Fields: <Field type=c_uint, ofs=0:0, bits=4> <Field
type=c_uint, ofs=0:4, bits=4> Instance Fields: 1 2
Bytes: 21,00,00,00



-- 
Rob Gaddi, Highland Technology
18 Otis St.
San Francisco, CA 94103
415-551-1700

[ctypes-users] Compiling ctypes statically?

[Roberto B. <bo...@gm...>]

Hello,

I have a python binary compiled statically, when I try to do the same with
ctypes (outside of python compilation using the tar.gz) I get error because
is trying to build the .so instead of a .a

Sorry I'm a bit lost with this, but anyways here is the compilation flags:

$> LDFLAGS="-Wl,-no-export-dynamic -static-libgcc -static -ldl
-L/usr/local/lib -L/usr/local/lib64 -lev" CPPFLAGS="-static -fPIC
-I/usr/local/include" /usr/local/python-static/bin/python setup.py build

Here is the output:

/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.4.6/crtbeginT.o: relocation
R_X86_64_32 against `__DTOR_END__' can not be used when making a shared
object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/crtbeginT.o: could not read symbols:
Bad value
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

Any help will be appreciated.

Thanks.
-- 
Roberto Bouza Fraga.
www: http://www.robertobouza.com
t: http://twitter.com/bouzafr - @bouzafr
e: bo...@gm...