> That means they need to be in memory anyway, right?
Actually no, GCC can optimize out pointer indirection like that if it ends up inlining the function (which it could in the kernel example, since it's static, relatively short, and has only three callers).
Another contrived example:
static int inlineme(int *lol, int lolol)
{
*lol += lolol;
return *lol * 5;
}
int test(int x)
{
int tmp = 5;
tmp += inlineme(&tmp, x);
return tmp;
}
... all of which compiles to (with -O2):
0000000000000000 <test>:
0: 83 c7 05 add $0x5,%edi
3: 8d 04 bf lea (%rdi,%rdi,4),%eax
6: 01 f8 add %edi,%eax
8: c3 retq
Note that "tmp" doesn't have to be a constant for that to happen.
As far as the actual kernel function, GCC ends up emitting:
(The only uncompressed kernel binary I had laying around was for my beaglebone black, sorry)
c0136fa0 <verify_reserved_gdb>:
c0136fa0: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
c0136fa4: e24dd02c sub sp, sp, #44 ; 0x2c
<snip>
c0136fbc: e3a03001 mov r3, #1
c0136fc0: e58d301c str r3, [sp, #28]
c0136fc4: e3a03005 mov r3, #5
c0136fc8: e58d3020 str r3, [sp, #32]
c0136fcc: e3a03007 mov r3, #7
c0136fd0: e58d3024 str r3, [sp, #36] ; 0x24
c0136fd4: e1a00007 mov r0, r7
c0136fd8: e28d101c add r1, sp, #28
c0136fdc: e28d2020 add r2, sp, #32
c0136fe0: e28d3024 add r3, sp, #36 ; 0x24
c0136fe4: ebffffd4 bl c0136f3c <ext4_list_backups>
... so in this case it does actually pass by reference.
That doesn't change my argument: an array is the more confusing way to do this, and in similar situations could prevent the compiler from making the optimization it did in my example.
