java传递指针,传递指针从C到Java成为空

I'm working on an Android app for x86 that requires some integration with C. I've been using swig/JNI to do the trick, and things have been running smoothly for the most part. However, pointers have been giving me some errors.

My issue is that I am able to successfully reference variable addresses in the emulator (ARM) but on a device (x86), things do not go as well.

Using the example from this link, I discovered that the address of any allocated variable in C becomes NULL once this address passes over to Java. For example...

Swig-generated JNI:

SWIGEXPORT jlong JNICALL Java_exampleJNI_new_1intp(JNIEnv *jenv, jclass jcls) {

jlong jresult = 0 ;

int *result = 0 ;

(void)jenv;

(void)jcls;

result = (int *)new_intp();

LOGI("Result is %x", result);

*(int **)&jresult = result;

LOGI("JResult is %x", jresult);

return jresult;

}

Source file containing new_intp():

static int *new_intp() {

return (int *) calloc(1,sizeof(int));

}

I have print statements checking the value of the address as it originates in C and passes over to Java. In new_intp(), the new variable is allocated a good looking address, but once this value returns to JNI and gets cast as a jlong, it turns to NULL.

In other words, *(int **)&jresult = result;causes jresult to be 0.

Why does this happen? Is there some particularity of x86 that disallows JNI to work with pointers? Or is it because I'm testing it on a physical device rather than an emulator?

Regards

解决方案

It looks to me like it could be an endianness issue.

*(int **)&jresult = result;

If int is 32 bits, and jresult is 64 bits, then on a big-endian architecture this could give unexpected results.

&jresult is a pointer to a 64-bit value, so if you cast it to a pointer to a 32-bit value, then you're pointing at the lower-addressed of the two constituent 32-bit words. In a big-endian system this will be the most significant word. So after writing a 32-bit word to the most significant end of the 64-bit value, you get a 64-bit value which is 2^32 times bigger than what you expect.

If your LOGI call is treating the parameter as a 32-bit int, and implicitly down-casting it from a 64-bit value, then it will give 0.

Can you see if this works instead?

jresult = (jlong) result;