I have a C function (composeKey) that has an input unsigned char* parameter ("key"). On the C side, "key" needs to be an empty 20 byte buffer structure. I'm assuming that a Java short array with a size of 20 would be the correct Java structure to pass composeKey's "key" parameter, but I'm unsure. Maybe a byte[20] is what i need. If that is correct, what SWIG Interface file modification is needed to generate the composeKey Java method with a short[] as input for the "key" parameter?
C Function:
int composeKey(const void* secret, int secret_len, unsigned char* key, int length);
Solution to your specific problem
Java doesn't really distinguish between short[20] and (e.g.) short[21] in its type system. You can do something that's pretty sensible quite simply though, by making the fact that the length of key is always 20 obvious to SWIG:
%module test
%include "arrays_java.i"
int func(unsigned char key[20]);
This can work even without changing the actual signature of your function directly - SWIG can wrap that, but have the wrapped code call a function that still takes unsigned char* quite sensibly:
%module test
%{
#include "header.h"
// fine even if it's func(unsigned char *key) in the header.
%}
%include "arrays_java.i"
int func(unsigned char key[20]);
If you call func from Java with an inappropriately sized array you'll get an IndexOutOfBoundsException exception thrown for you automatically by the code that SWIG generates.
General solution
In this specific case "arrays_java.i" provides a suitable typemap already. In the more general case this works by providing SWIG with a typemap for unsigned char [ANY] (literally write ANY in SWIG typemap syntax). This then gets instantiated for specific values in place of ANY (sort of like a template in C++), you can then access the specific value of ANY in your typemap using $1_size and supply code that the sizes gets filled in to look (some JNI details omitted for brevity) roughly like:
if (GetArrayLength(arg) != $1_size) {
// Code to throw a Java Exception ...
Which then in the generated wrapper becomes:
if (GetArrayLength(arg) != 20) {
// Code to throw a Java Exception ...
Related
I am using a flexible array in the structure. So I want to change the memory allocated for that structure with some of my own code. Basically I want to change the new_structname() and structname_variable_set() functions.
typedef struct vector{
int x;
char y;
int arr[0];
} vector;
here, SWIG generated new_vector() function to allocate memory by calling calloc(1,sizeof(struct vector)) where swig will not handle these type of structure in a special manner. So we need to modify the swig generated new_vector() in order to allocate memory for the flexible array. So is there any way to handle this?
There are a few ways you can do this. What you're looking for though is %extend. That lets us define new constructors and implement them as we see fit. (It even works with a C compiler, they're only constructors from the perspective of the target language).
Using your vector as a starting point we can illustrate this:
%module test
%include <stdint.i>
%inline %{
typedef struct vector{ int x; char y; int arr[0]; }vector;
%}
%extend vector {
vector(const size_t len) {
vector *v = calloc(1, sizeof *v + len);
v->x = len;
return v;
}
}
With this SWIG synthesises a new_vector function in the generated module code as you'd hoped.
I also assumed that you want to record the length inside the struct as one of its members. If that's not the case you can simply delete the assignment I made.
I am trying to write a custom function to carry out sum. I followed this question Cuda Thrust Custom function to take reference.Here is how I have defined my functor
struct hashElem
{
int freq;
int error;
};
//basically this function adds some value to to the error field of each element
struct hashErrorAdd{
const int error;
hashErrorAdd(int _error): error(_error){}
__host__ __device__
struct hashElem operator()(const hashElem& o1,const int& o2)
{
struct hashElem o3;
o3.freq = o1.freq;
o3.error = o1.error + (NUM_OF_HASH_TABLE-o2)*error; //NUM_OF_HASH_TABLE is a constant
return o3;
}
};
struct hashElem freqError[SIZE_OF_HASH_TABLE*NUM_OF_HASH_TABLE];
int count[SIZE_OF_HASH_TABLE*NUM_OF_HASH_TABLE];
thrust::device_ptr<struct hashElem> d_freqError(freqError);
thrust::device_ptr<int> d_count(count);
thrust::transform(thrust::device,d_freqError,d_freqError+new_length,d_count,hashErrorAdd(perThreadLoad)); //new_length is a constant
This code on compilation gives the following error:
error: function "hashErrorAdd::operator()" cannot be called with the given argument list
argument types are: (hashElem)
object type is: hashErrorAdd
Please can anybody explain to me why I am getting this error? and how I can resolve it. Please comment in case I am not able to explain the problem clearly. Thankyou.
It appears that you want to pass two input vectors to thrust::transform and then do an in-place transform (i.e. no output vector is specified).
There is no such incarnation of thrust::transform
Since you have passed:
thrust::transform(vector_first, vector_last, vector_first, operator);
The closest matching prototype is a version of transform that takes one input vector and creates one output vector. In that case, you would need to pass a unary op that takes the input vector type (hashElem) only as an argument, and returns a type appropriate for the output vector, which is int in this case, i.e. as you have written it (not as your intent). Your operator() does not do that, and it cannot be called with the arguments that thrust is expecting to pass to it.
As I see it, you have a couple options:
You could switch to the version of transform that takes two input vectors and produces one output vector, and create a binary op as functor.
You could zip together your two input vectors, and do an in-place transform if that is what you want. Your functor would then be a unary op, but it would take as argument whatever tuple was created from dereferencing the input vector, and it would have to return or modify the same kind of tuple.
As an aside, your method of creating device pointers directly from host arrays looks broken to me. You may wish to review the thrust quick start guide.
I have a C function like this one:
int make_call(char* to, int *call_id);
and a very simple interface file:
%include "typemaps.i"
%include "enums.swg"
%include "arrays_java.i"
%header %{
#include <my_header.h>
%}
/* Map "int*" as input & output */
%apply int *INOUT { int * };
This works just fine. In my SWIG file I get:
public static int make_call(String to, int[] call_id) {..}
and I can call it creating an int[] with one element. All good so far.
However as the call_id can be quite large it needs to be a long so I changed this in the C API and I added to the .i file this line:
%apply long *OUTPUT { long * };
I have tried several variants including trying to apply what is said in the java.html doc for SWIG but I always end up with an int[] beeing generated or maybe the swigtype for long that I am not able to use from Java. I am just not able to make it generate a long[] that I am expecting.
I tried just making it a double like this:
%apply double *OUTPUT { double * };
and it works as expected and I get my double[] call_id in the generated interface.
Is there any pitfalls with the long type? It would seem wierd right?
Try one of:
unsigned long
unsigned int
long long
The problem involved a JAVA call to a C-function (API) which returned a pointer-to-pointer as an argout argument. I was trying to call the C API from JAVA and I had no way to modify the API.
Using SWIG typemap to pass pointer-to-pointer:
Here is another approach using typemaps. It is targetting Perl, not Java, but the concepts are the same. And I finally managed to get it working using typemaps and no helper functions:
For this function:
typedef void * MyType;
int getblock( int a, int b, MyType *block );
I have 2 typemaps:
%typemap(perl5, in, numinputs=0) void ** data( void * scrap )
{
$1 = &scrap;
}
%typemap(perl5, argout) void ** data
{
SV* tempsv = sv_newmortal();
if ( argvi >= items ) EXTEND(sp,1);
SWIG_MakePtr( tempsv, (void *)*$1, $descriptor(void *), 0);
$result = tempsv;
argvi++;
}
And the function is defined as:
int getblock( int a, int b, void ** data );
In my swig .i file. Now, this passes back an opaque pointer in the argout typemap, becaust that's what useful for this particular situation, however, you could replace the SWIG_MakePtr line with stuff to actually do stuff with the data in the pointer if you wanted to. Also, when I want to pass the pointer into a function, I have a typemap that looks like this:
%typemap(perl5, in) void * data
{
if ( !(SvROK($input)) croak( "Not a reference...\n" );
if ( SWIG_ConvertPtr($input, (void **) &$1, $1_descriptor, 0 ) == -1 )
croak( "Couldn't convert $1 to $1_descriptor\n");
}
And the function is defined as:
int useblock( void * data );
In my swig .i file.
Obviously, this is all perl, but should map pretty directly to Java as far as the typemap architecture goes. Hope it helps...
[Swig] Java: Using C helper function to pass pointer-to-pointer
The problem involved a JAVA call to a C-function (API) which returned a pointer-to-pointer as an argout argument. I was trying to call the C API from JAVA and I had no way to modify the API.
The API.h header file contained:
extern int ReadMessage(HEADER **hdr);
The original C-call looked like:
HEADER *hdr;
int status;
status = ReadMessage(&hdr);
The function of the API was to store data at the memory location specified by the pointer-to-pointer.
I tried to use SWIG to create the appropriate interface file. SWIG.i created the file SWIGTYPE_p_p_header.java from API.h. The problem is the SWIGTYPE_p_p_header constructor initialized swigCPtr to 0.
The JAVA call looked like:
SWIGTYPE_p_p_header hdr = new SWIGTYPE_p_p_header();
status = SWIG.ReadMessage(hdr);
But when I called the API from JAVA the ptr was always 0.
I finally gave up passing the pointer-to-pointer as an input argument. Instead I defined another C-function in SWIG.i to return the pointer-to-pointer in a return value. I thought it was a Kludge ... but it worked!
You may want to try this:
SWIG.i looks like:
// return pointer-to-pointer
%inline %{
HEADER *ReadMessageHelper() {
HEADER *hdr;
int returnValue;
returnValue = ReadMessage(&hdr);
if (returnValue!= 1) hdr = NULL;
return hdr;
}%}
The inline function above could leak memory as Java won't take ownership of the memory created by ReadMessageHelper, since the HEADER instance iscreated on the heap.
The fix for the memory leak is to define ReadMessageHelper as a newobject in order for Java to take control of the memory.
%newobject ReadMessageHelper();
JAVA call now would look like:
HEADER hdr;
hdr = SWIG.ReadMessageHelper();
If you are lucky, as I was, you may have another API available to release the message buffer. In which case, you wouldn’t have to do the previous step.
William Fulton, the SWIG guru, had this to say about the approach above:
“I wouldn't see the helper function as a kludge, more the simplest solution to a tricky problem. Consider what the equivalent pure 100% Java code would be for ReadMessage(). I don't think there is an equivalent as Java classes are passed by reference and there is no such thing as a reference to a reference, or pointer to a pointer in Java. In the C function you have, a HEADER instances is created by ReadMessage and passed back to the caller. I don't see how one can do the equivalent in Java without providing some wrapper class around HEADER and passing the wrapper to the ReadMessage function. At the end of the day, ReadMessage returns a newly created HEADER and the Java way of returning newly created objects is to return it in the return value, not via a parameter.”
I have the below structure in my SWIG interface file and thusly my sample.h header file. I'm assuming the sockaddr, ios_boolean and unsigned char definitions from this structure are the reason why I get the below generated classes. If I know the type on that ios_boolean and unsigned char map to on the Java side is there a way to use an %apply to get rid of the generated pointer classes? I tried %apply int {ios_boolean}; but then I get a SWIGTYPE_p_boolean.java. Any ideas?
%rename (Sample) sample_details_t_;
typedef struct sample_details_t_ {
ios_boolean is_allowed;
unsigned char mac[11];
} sample_t;
generates:
SWIGTYPE_p_unsigned_char.java
SWIGTYPE_p_ios_boolean.java
Exception:
[exec] ewapi_wrap.c:982: error: `true' undeclared (first use in this function)
[exec] ewapi_wrap.c:982: error: (Each undeclared identifier is reported only once
[exec] ewapi_wrap.c:982: error: for each function it appears in.)
[exec] ewapi_wrap.c:982: error: `false' undeclared (first use in this function
You probably want to do something like:
%include <arrays_java.i>
%rename (Sample) sample_details_t_;
%apply bool { ios_boolean };
typedef struct sample_details_t_ {
ios_boolean is_allowed;
unsigned char mac[11];
} sample_t;
This wraps mac as short[] (with constraints on the array size) and is_allowed as boolean on the Java side and results in these files:
Sample.java test.java testJNI.java
Make sure you delete any old SWIGTYPE_*.java files that are lying around from older versions of your SWIG interface, they won't get deleted automatically and might fail to compile if you do something like javac *.java.