Ting 이네 Software 이야기

Most Android device is 32bit machine. So, many application assumes that host machine is 32bit system.
And in general, there is no difference developing Android-natvie-library between 64bit and 32bit build machine.

But, here is usual step for developing Android-native-library.
(1) Developing and verifying code at build machine.
(2) Porting to NDK build system.

Most developers turns on full-warning-option at compile to detect bugs at early stage.
But, building and verifying codes assuming 32bit host machine at 64bit machine always issues type casting warning due to different type size.
Especially, between pointer and integer.

For example, many Android JAVA application uses int - jint - as a type to contain native pointer with assumption of 32bit-host-system.
Building this code at 64bit build system to verify code issues type casting warning, even if code itself is built perfectly at NDK build system.
And it is worse that this code doesn't work at 64bit Android host machine, even though it is not popular.

To reduce this warnings (for easy-verifying of library code at build machine), in my opinion, using long - jlong - instead of jint as a type for containing native pointer is better unless memory space is extremely critical.
And to make compiler be happy, using macro can be a good choice.
Here is example of macro for type-casting between pointer and integer - jlong.
(This sample works well without warning at 32bit/64bit build/host system).

#define ptr2jlong(v) ((jlong)((intptr_t)(v)))
#define jlong2ptr(v) ((void*)((intptr_t)(v)))

This is just simple example for portability issues.
Making portable code is always very difficult...

Conflicting symbol name with library is not rare.
So, I want suggest my personal opinion to avoid this.

1. Before release code/library, change all symbol name of source code into unique name (random string) with tool.
2. Determine appropriate symbol name that should be exported.
  (There can be two options. (*a)One is "changing exported symbols into agreed name". (*b)The other is "providing header file that includes all exported symbol with recommended name. And user can re-define necessary or conflicting symbol into expected one")

Let's see the example.

 a. (original source code)
  ...
  MY_UINT32 my_name;
  ...
  MY_UINT16 company_name;
  ..

 b. (symbol-changing-tool setting) - change symbol from 'a.'
  ...
  MY_UINT32 => FooRgYaIIkdjdtq40238dkkRkwUTTT00001
  MY_UINT16 => FooRgYaIIkdjdtq40238dkkRkwUTTT00002
  my_name => FooRgYaIIkdjdtq40238dkkRkwUTTT00003
  compay_name => FooRgYaIIkdjdtq40238dkkRkwUTTT00004
  ...

 c. (auto-modified original source code)
  ...
  FooRgYaIIkdjdtq40238dkkRkwUTTT00001 FooRgYaIIkdjdtq40238dkkRkwUTTT00003;
  ...
  FooRgYaIIkdjdtq40238dkkRkwUTTT00002 FooRgYaIIkdjdtq40238dkkRkwUTTT00004;
  ...

-------- (*a) -------------

 d1. agreed name
  MY_UINT32 => UINT32
  MY_UINT16 => UINT16
  my_name => company_name
  company_name => firm_name

 d2(*a). (symbol-changing-too setting) - change symbol from 'c.' based on 'd.'
  FooRgYaIIkdjdtq40238dkkRkwUTTT00001 => UINT32
  FooRgYaIIkdjdtq40238dkkRkwUTTT00002 => UINT16
  FooRgYaIIkdjdtq40238dkkRkwUTTT00003 => company_name
  FooRgYaIIkdjdtq40238dkkRkwUTTT00004 => firm_name

---------- (*b) ---------

 d. (header file that has recommended symbol)
  /*symbol_match.h */
  /*=============== symbol-matching table ================= */
  ...
  #define UINT32 FooRgYaIIkdjdtq40238dkkRkwUTTT00001
  #define UINT16 FooRgYaIIkdjdtq40238dkkRkwUTTT00002
  #define my_name FooRgYaIIkdjdtq40238dkkRkwUTTT00003
  #define company_name FooRgYaIIkdjdtq40238dkkRkwUTTT00004
  ...

--------------------

 e. (Releasable code - base source code for building library)
  ...
  UINT32 company_name;
  ...
  UINT16 firm_name;
  ...

I think this way is worth considering to make very portable library.