Parsing D3DX10math.h ends in an Out Of Memory error after a long wait

[ochafik]

From @cessationoftime on January 11, 2012 3:36

Using JNAerator-0.9.8-shaded.jar

config.jnaerator looks like this:

-DWIN32_LEAN_AND_MEAN= 
-DNOCOMM= 
-DNOSOUND= 
-DNOKANJI= 
-DNOSYSMETRICS= 
-DNOICONS= 
-DNOSERVICE= 
-DNOSOUND= 
-DNOTEXTMETRIC= 
-DNOKANJI= 
-DNOHELP= 
-DNOPROFILER= 
-DNOMCX= 
-DWINVER=0x0502 
-D_WIN32_WINNT=0x0502 
-D_WIN32_IE=0x0603 
-root com.redsoft.keyhole.windows.api 
-scalaStructSetters 
-D_MSC_VER=1600 
-DMIDL_PASS=1 
-DHRESULT=int 
-DDWORD=int 
-DBYTE=char 
-DSIZE_T=size_t 
-D__stdcall= 
-D__cplusplus=1 
-DVOID=void 
-DBOOL=int 
-DPVOID=void* 
"-DMIDL_INTERFACE(x)=struct __declspec(uuid(x)) __declspec(novtable)" 
"-IC:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include" 
"-IC:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include" 
"-IC:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include" 
-library d3dx10 
"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include\d3d10.h" 
"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include\d3dx10.h" 
//running out of memory GC overhead on this header
"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include\d3dx10math.h" 
"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include\d3dx10core.h" 
"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include\d3dx10tex.h" 
"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include\d3dx10mesh.h" 
"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include\d3dx10async.h" 
-noJar -noComp 
-o src/main/jnaerated 
-v 
-runtime BridJ 

JNAerator is unable to give any serious output unless one comments out the #include for the math header in d3dx10.h, then it is able to parse the other files and can ignore d3dx10math.h

JNAerator appears to be failing at approx line 90 of d3dx10math.h when it reaches the following struct:

typedef struct D3DXFLOAT16 
{ 
#ifdef __cplusplus 
public: 
    D3DXFLOAT16() {}; 
    D3DXFLOAT16( FLOAT ); 
    D3DXFLOAT16( CONST D3DXFLOAT16& ); 
    // casting 
    operator FLOAT (); 
    // binary operators 
    BOOL operator == ( CONST D3DXFLOAT16& ) const; 
    BOOL operator != ( CONST D3DXFLOAT16& ) const; 
protected: 
#endif //__cplusplus 
    WORD value; 
} D3DXFLOAT16, *LPD3DXFLOAT16; 

One can get pretty good output from d3dx10math.h by using "#undef __cplusplus" to ignore the faulty sections of the file and then redefining it at the end of d3dx10math.h

see: http://groups.google.com/group/nativelibs4java/browse_thread/thread/2bbe5a69e681ca51

Copied from original issue: ochafik/nativelibs4java#230

[ochafik]

Hi Chris,

Just so you know, I'm progressing on this : isolated a parsing regression that can be worked around by setting "typedef unsigned long *ULONG_PTR;" in a prelude.h that you'd include before the other files, and for some reason if I include d3d10.h twice I get things to work. This is with the latest snapshot, available on Sonatype OSS : https://oss.sonatype.org/content/groups/public/com/nativelibs4java/jnaerator/0.9.10-SNAPSHOT/

Please bear with me as I'm working on a fix (gotta find when I regressed the grammar !)

Cheers

[ochafik]

From @cessationoftime on January 14, 2012 17:5

Thanks for looking into that I will try your work around later though. I am currently trying to figure out how to use DirectInput through Scala. And I wont need the DirectX until after this piece is complete.

Also, I may have found a new problem or possibly another symptom of this problem. I have found that I get better output if I split header files in half. For example:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\windef_part1.h"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\winnt_part1.h"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\basetsd.h"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\winnt_part2.h"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\windef_part2.h"    

winnt.h has "#include basetsd.h" in the middle of the file and likewise windef.h has #include winnt.h" in the middle of the file. So when I wasn't getting the results I expected I tried splitting the files down the middle on the #include lines and nesting them in the config (as shown above) and the output improved. Could this be related? You said including d3d10.h twice made things work, and what I did seems somewhat similar.