For reference, see discussion on #997.

I just updated my project to JNA 5.0.0 and went through the process of removing classes I implemented locally that are now in JNA. The LibC.SysInfo class that I submitted seems to not behave as we intended. I had all the code implemented in my local class except for the @FieldOrder annotation, so inclusion of the annotation (in the JNA class) is causing test failures.

Multiple Travis CI tests fail with the same underlying error:

java.lang.Error: Structure.getFieldOrder() on class com.sun.jna.platform.linux.LibC$Sysinfo does not provide enough names [13] ([_f, bufferram, freehigh, freeram, freeswap, loads, mem_unit, procs, sharedram, totalhigh, totalram, totalswap, uptime]) to match declared fields [12] ([bufferram, freehigh, freeram, freeswap, loads, mem_unit, procs, sharedram, totalhigh, totalram, totalswap, uptime])

Ignoring the strange wording (not enough when 13 > 12 should be "too many") it does look like the intent to omit the _f from a 64-bit build isn't working correctly. I suspect the error is probably on line 92-94:

            if (PADDING_SIZE > 0) {
                fieldOrder.add("_f");
            }

Given the existing annocation the _f is already there, so I think this conditional should really check if it's equal to zero and remove the _f (as is done in the getFieldList() method preceding it.)

Happy to submit a PR to fix this, but wanted to get confirmation that's the right way to go, as this FieldOrder stuff still seems like a little bit of black magic to me.

Separately, I'm surprised this isn't being caught in a test case... or perhaps the test case is being run on 32-bit and is rather happy with the padding.