1

I would like to use SWIG on Windows for building 64 bit applications. I have a class that has a pointer in it to a buffer, and because I would like to interface with a .NET class, the pointer is declared as intptr_t.

The problem is that the standard SWIG stdint.i assumes that intptr_t is either int (on 32 bit environment) or long (on 64 bit environment). While this is true on Unix, it is false on Windows. Does anyone have either similar experience or any ideas how to create a workaround for this?

I already set up the typemaps needed for the intptr_t => IntPtr conversion and it is working fine in 32 bit environment, but it truncates the pointer in 64 bit environment.

agazso
  • 165
  • 2
  • 8

1 Answers1

1

Ok, I will answer my own question. It seems that this is a bug in SWIG on Windows, that it treats long as int64 on 64-bit Windows, while in reality it is an int32. See more about this topic here: What is the bit size of long on 64-bit Windows?

The other problem with SWIG is that it differentiates 32 and 64 bit code, but the reason I used intptr_t was to avoid bitness issues, as by definition it gives an integer large enough to hold a pointer.

So what I did at the end was to write a script that I run after generating the wrapper to fix the type signatures from int to intptr_t. While this is not elegant, I already have to do this for other reasons for my Python and PHP wrappers.

Community
  • 1
  • 1
agazso
  • 165
  • 2
  • 8