[mFixman]

I used to slay with this in code golfing competitions from TopCoder, where you had to implement a function to solve a particular problem, thanks to C pointer maths and the gcc generally putting function arguments in order in the stack.

Turns out, these two are equivalent in practice (but UB in the C++ standard):

    double solve(double a, double b, double c, double d) {
      return a + b + c + d;
    }

    double solve(double a ...) {
      return a + 1[&a] + 2[&a] + 3[&a];
    }

[mananaysiempre]

> Turns out, these two are equivalent in practice

Not in the x86-64 SysV ABI they aren’t. The arguments will be passed in registers (yes, even the variadic ones), so how your compiler will interpret 1[&a] is anybody’s guess. (For me, x86_64-unknown-linux-gnu-g++ -O2 yields, essentially, return a+a+a+a; which is certainly an interpretation. I’m also getting strange results from i686-unknown-linux-gnu-g++ -O2, but my x87 assembly is rusty enough that I don’t really get what’s going on there.)

[jcranmer]

Example compiler explorer view: https://godbolt.org/z/b5z3q1616

Clang does the sensible thing with UB and just returns poison (a form of undefined value) in both cases, which manifests as do nothing on x86-64 and load a zero value on i386, because you need to push something on the stack and fldz is one of the cheapest ways to push something. Meanwhile, gcc is in both cases for the UB variant returning a + a + a + a;

FWIW, going back through older gcc versions, it seems i386 gcc stops implementing 'add the arguments' in version 11.1, although it's not until 15.1 that it has a sensible assembly for 'a + a + a + a'. The x86-64 gcc version is broken in 4.0 (where it stops copying the register arguments to the stack when va_start isn't called, I guess). Then it's adding xmm0 to the top 3 values on the stack until 11.1, when it's adding 'a + a + a + a', although not sensibly until version 15.1.

[Sharlin]

> return a+a+a+a; which is certainly an interpretation.

Zero is the only valid index of &a, so I presume the compiler just assumes that all the indexes in 1[&a] + 2[&a] etc must be zero. Even though they're in this case compile-time constants – the optimizer could check but why bother given that it's UB anyway. I assume modern C/C++ compilers have some flag to diagnose indexing that's known to be OOB at compile time.

[mananaysiempre]

I’m so used to sticking -Wall in my compilation flags the moment I write a build script that I didn’t realize it wasn’t there for this quick experiment. Yes, thank you, there are indeed diagnostics once you ask for them:

  test.cpp: In function ‘double solve(double, ...)’:
  test.cpp:4:20: warning: array subscript 1 is outside array bounds of ‘double [1]’ [-Warray-bounds=]
      4 |     return a + 1[&a] + 2[&a] + 3[&a];
        |                ~~~~^
  test.cpp:3:58: note: at offset 8 into object ‘a’ of size 8
      3 | extern "C" __attribute__((noinline)) double solve(double a, ...) {
        |                                                   ~~~~~~~^
  [repeat twice more for the other two accesses]

[camel-cdr]

K&R syntax is -1 char, if you are in C:

    double solve(double a,double b,double c,double d){return a+b+c+d;}
    double solve(double a...){return a+1[&a]+2[&a]+3[&a];}
    double solve(a,b,c,d)double a,c,b,d;{return a+b+c+d;}

[maccard]

>turns out these two are equivalent in practice

Err no; https://gcc.godbolt.org/z/sW3ea58oc

They're equivalent on GCC.

[Joker_vD]

    double solve(double a[]) {
      return 0[a] + 1[a] + 2[a] + 3[a];
    }

    solve((double[]){1, 2, 3, 4});

The cast in the invocation can be macro-ed away. And the best thing is, the actual stack layout and data movement/shuffling is pretty much identical to the approach with <stdargs.h>, and with no UB or compiler intrinsics.

[kevin_thibedeau]

That's a compound literal, not a cast.