We're using the 64 bit packages for Debian, writing our own python 2.7 code to access the provided AD2 library using 'ctypes' module. I'm trying to track down a tricky bug and wondering what the library was compiled with: C or C++ ? Is the dwf.h definition file exactly correct with regards to parameter types (char vs unsigned char
Trying to see if the size of the parameters, ctypes.c_bool() vs ctypes.c_int(), e.g., matters. Or c_byte() vs c_ubyte(). Since afaik C doesn't have 'bool' type, knowing if this is a C++ library would help me decide.
Similar inconsistencies:
Example code snippet: /usr/share/digilent/waveforms/samples/py/dwfconstants.py
where my reference tells me 'c_ubyte' is what we should be using for 'unsigned char', not c_byte().
Going by the dwf.h file, I would not use the definition examples provided in dwfconstants.py, but change to c_ubyte(), for example.
In the end, most of these probably won't matter, but the bug I'm chasing seems to involve corruption of the runtime stack (moving a FDwf call into a subroutine gives different behavior than calling it from one up), so I'm being paranoid about the ctypes interface since it's easy to make a mistake there.
This on Debian 8.6 with installed:
+++-=======================-================-================-===================================================
ii digilent.adept.runtime 2.16.5 amd64 Digilent Adept Runtime
ii digilent.adept.utilitie 2.2.1 amd64 Digilent Adept Utilities
ii digilent.waveforms 3.3.7 amd64 Digilent WaveForms
Question
Torfey 0
We're using the 64 bit packages for Debian, writing our own python 2.7 code to access the provided AD2 library using 'ctypes' module. I'm trying to track down a tricky bug and wondering what the library was compiled with: C or C++ ? Is the dwf.h definition file exactly correct with regards to parameter types (char vs unsigned char
Trying to see if the size of the parameters, ctypes.c_bool() vs ctypes.c_int(), e.g., matters. Or c_byte() vs c_ubyte(). Since afaik C doesn't have 'bool' type, knowing if this is a C++ library would help me decide.
Similar inconsistencies:
Example code snippet: /usr/share/digilent/waveforms/samples/py/dwfconstants.py
But dwf.h, that presumaly the library was compiled with:
typedef unsigned char BYTE; typedef BYTE TRIGSRC; const TRIGSRC trigsrcNone = 0; const TRIGSRC trigsrcPC = 1;
where my reference tells me 'c_ubyte' is what we should be using for 'unsigned char', not c_byte().
Going by the dwf.h file, I would not use the definition examples provided in dwfconstants.py, but change to c_ubyte(), for example.
In the end, most of these probably won't matter, but the bug I'm chasing seems to involve corruption of the runtime stack (moving a FDwf call into a subroutine gives different behavior than calling it from one up), so I'm being paranoid about the ctypes interface since it's easy to make a mistake there.
This on Debian 8.6 with installed:
Thanks much.
Link to post
Share on other sites
5 answers to this question
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now