Print native layout of struct

[Flowdalic]

Is there a way to let jnr-ffi print out the native layout of a struct? Or even better, print the native layout and the contents of a instance of Struct.

[basshelal]

The only way one could do that is using reflection to view the members of a Java Struct but this is based on the mapping you provide, such a function wouldn't be too difficult to implement if you've used Java reflection before.

However, if you're asking about JNR-FFI viewing and printing the layout of a native struct, as in a C struct, then I believe that is impossible, since to JNR-FFI a struct is just a block of memory and that can be arranged and laid out in any way one may see fit.

Even C doesn't know the layout of a block of memory at runtime unless you tell it to cast to a known struct type which at that point it will just trust that you know what you're doing.

For example, a block of memory made of 8 bytes could be:

• 8 1 byte members
• 1 64 byte member (long, long long, double, or even an inner struct or array)
• 2 32 byte members (int, long (on some platforms), float, or even an inner struct or array)
• and many many more possibilities which may include padding such as end padding

Unless I'm completely wrong or am unaware of something, I believe this is impossible. A struct is nothing more than an abstraction for a specific layout of a block of memory which the programmer declares.

[Flowdalic]

Thanks for your answer.

My reasoning is that some entity within jnr-ffi must have knowledge about the native layout of a struct. After all, it is jnr-ffi which transforms from the Java layer's Struct to the native memory representation of the (C-layer) "struct".

Let's say you have

struct my_struct {
    int32_t bar;
    int64_t baz;
}

under certain layout rules, the C compiler will potentially layout this struct into 128 bytes:

• 0..31 bar
• 32..63 padding
• 64…127 baz

In jnr-ffi, this may be mapped as

class MyStruct extends Struct {
   public final Signed32 bar = new Signed32();
   public final Signed64 baz = new Signed64();
   …
}

And when you have a function like void my_fun(struct my_struct *in), which you may map via jnr-ffi to void MyFun(MyStruct in), then jnr-ffi has to create a native memory buffer for MyStruct/struct my_struct and has to know how the fields/members of the struct are placed in this memory buffer.

Basically I hoped that jnr-ffi provides something like

   var myStruct = new MyStruct()
   myStruct.printNative()

which outputs something like

MyStruct
- 0..31 bar = -23
- 32..63 padding
- 64…127 baz = 42

[basshelal]

I think I understand what you mean.

Technically yes, the internals of JNR-FFI ,jffi especially, know generally about the Struct's layout but still, only based on what they are given in the Java mapping.

If the native C struct is 8 bytes composed of 8 1 byte members and your Java mapping is (for whatever reason) incorrectly, an array of 8 bytes or a double (8 bytes) or long long (8 bytes), everything will still work as expected and JNR-FFI will believe that it was whatever you claimed it to be.

What I'm trying to say is, JNR-FFI has no idea what the native struct actually is, in fact, JNR-FFI has no idea about anything in the native library, it only uses your mappings and indeed trusts you to be correct because indeed, there is no way to verify anything from a native library, especially one that is stripped of debug symbols (which most release versions are). The only thing JNR-FFI knows is (when a library is loaded) if a specific symbol (function or variable) exists or not, JNR-FFI isn't even able to list all the symbols it sees (though this should be possible). What I'm trying to say is JNR-FFI uses and trusts your mappings for everything.

However, as in the case you mentioned, where you do indeed map the Struct correctly and you want to print a nice layout of it, JNR-FFI doesn't yet have a way to do this nicely where each member would contain its name, offset, size and value for you.

Struct.toString comes close returning each field's toString value, but this includes non Struct fields you may have and doesn't do offsets and sizes. This theoretically shouldn't be too hard to add as a feature but would take some time and refactoring. I have struggled with adding and maintaining the codebase because it's quite convoluted, perhaps you may be able to do something and contribute with a Pull Request. The maintainer @headius is very welcoming of contributions and if you expected this feature then you may not be first, just the first to ask it.