#include <stdarg.h>

The stdarg API, which allows you to use a variable number of arguments to a function in C, is pretty fun. However, it's also pretty limited in what it allows, to a degree that it invites people to try and find workarounds to things you can't do with the API as it is documented.

Unfortunately, this almost always breaks when the software is compiled on hardware that happens to be not your own, as there is a reason why stdarg is implemented the way it is: portability.

A (not so) recent discussion on #debian-devel on OFTC showed to me how this confuses many people. Don't worry—it confused me too, the first time I had to think about it.

The problem is that in order for stdarg to be able to do what it does, it needs to read function arguments from whereever they are stored. Where that actually is depends on the operating system and the hardware you're using; it could be on the stack, but e.g., the SPARC architecture actually has a mechanism to pass parameters using processor registers (although those are most likely not used when stdarg is in use, since the number of parameters that can be passed that way is obviously pretty limited). If parameters are on the stack, then you may be able to just access the memory as you would access any random variable; but it could also be the case that you need to take some specific steps to access the stack, or perhaps your architecture or operating system has some protection for stack-based security attacks, which would make it impossible to directly access memory on the stack that is actually part of another subroutine.

So if you try to do anything that isn't defined in the stdarg api (like trying to figure out the number of arguments by peeking inside the va_list data type, or passing a va_list to another function without using the C99 va_copy macro) will break. Yes. Very sorry.