1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
ctypes code generator TODO list
###############################
.. contents::
gccxml bugs
===========
I should submit these bugs to the gccxml bug tracker:
gccxml problems with 64-bit constants
-------------------------------------
On 64-bit Linux, 64-bit constants miss the 32 highest bits.
sizeof(long double) problem on Windows
--------------------------------------
MSVC and gccxml seem to disagree in the size of long double. This
is how the C compiler behaves::
C:\>type x.c
#include <stdio.h>
int main(int argc, char **argv)
{
printf("sizeof(float) = %d\n", sizeof(float));
printf("sizeof(double) = %d\n", sizeof(double));
printf("sizeof(long double) = %d\n", sizeof(long double));
return 0;
}
C:\>x
sizeof(float) = 4
sizeof(double) = 8
sizeof(long double) = 8
C:\>
and this is what gccxml does::
typedef float _float;
typedef double _double;
typedef long double _long_double;
<?xml version="1.0"?>
<GCC_XML cvs_revision="1.114">
<Namespace id="_1" name="::" members="_4 _6 _8 " mangled="_Z2::" demangled="::"/>
<Namespace id="_2" name="std" context="_1" members="" mangled="_Z3std" demangled="std"/>
<FundamentalType id="_3" name="long double" size="96" align="32"/>
<Typedef id="_4" name="_long_double" type="_3" context="_1" location="f0:3" file="f0" line="3"/>
<FundamentalType id="_5" name="double" size="64" align="64"/>
<Typedef id="_6" name="_double" type="_5" context="_1" location="f0:2" file="f0" line="2"/>
<FundamentalType id="_7" name="float" size="32" align="32"/>
<Typedef id="_8" name="_float" type="_7" context="_1" location="f0:1" file="f0" line="1"/>
<File id="f0" name="c:/dokume~1/thomas~1.ion/lokale~1/temp/tmpfa3lht.h"/>
</GCC_XML>
The problem is this line (size="96" -> 12 bytes) ::
<FundamentalType id="_3" name="long double" size="96" align="32"/>
MSDN documents that "the representation of 'long double' and 'double'
is identical. However, 'long double' and 'double' are separate types."
The docs are unclear about the size (8 bytes or 10 bytes), the
compiler implements 8 bytes, see above.
codegenerator bugs
==================
long double
-----------
``ctypes`` does not support the ``long double`` data type.
C99 _Complex type
-----------------
Do we need the C99 _Complex data type?
Refactoring
-----------
Refactor the code so that function generation can be easily adjusted
in subclasses of the code generator.
- will be addressed by integrating the patch that Mike Fletcher made.
Documentation (there is now something in the wiki).
inline functions (hm, is this really a problem?
-----------------------------------------------
The codegenerator should not generate code for inline functions.
Assume a header file containing this C code snippet::
#ifdef __cplusplus
__inline int IsEqualGUID(REFGUID rguid1, REFGUID rguid2)
{
return !memcmp(&rguid1, &rguid2, sizeof(GUID));
}
#endif
gccxml will generate this XML output (wrapped for readability)::
<Function id="_4898" name="IsEqualGUID" returns="_3989"
context="_1" location="f14:160" file="f14" line="160" endline="162" inline="1">
<Argument name="rguid1" type="_9847" location="f14:160" file="f14" line="160"/>
<Argument name="rguid2" type="_9847" location="f14:160" file="f14" line="160"/>
</Function>
and the code generator will generate this Python code::
IsEqualGUID = CDLL('ole32').IsEqualGUID
IsEqualGUID.restypes = c_int
# IsEqualGUID(rguid1, rguid2)
IsEqualGUID.argtypes = [POINTER(GUID), POINTER(GUID)]
ideas for improvement
=====================
Limitations of gccxml
---------------------
- typedefs used in function argument lists are handled differently
than in structure fields. Cosmetic bug?
- No info available about where #define'd symbols came from.
(Would it be possible to implement a C parser in pure Python?
PLY would probably be able to handle this, but we need a CPP
as well).
(Ah - there's a CPP in pure Python in fnorb, by Martin v. Loewis of
course.)
|
