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.)