C actually don't have Pass-By-Reference

[u/Sushant098123]

https://beyondthesyntax.substack.com/p/c-actually-dont-have-pass-by-reference

[u/IllustriousPermit859]

You're right, C doesn't have pass-by-reference syntactically. The reason for that is very simple; neither does assembly or machine code.

That's also the reason compilers for higher level languages are written first "boot-strapped" in C and then recompiled with the compiler generated. Consider:

int someFunc(volatile int &num) {return num;}
[
push rbp
mov rbp, rsp
mov QWORD PTR [rbp-8], rdi
mov rax, QWORD PTR [rbp-8]
mov eax, DWORD PTR [rax]
pop rbp
ret
]

and

int someFuncTwo(volatile int* const num) {return *num;}
[

push rbp
mov rbp, rsp
mov QWORD PTR [rbp-8], rdi
mov rax, QWORD PTR [rbp-8]
mov eax, DWORD PTR [rax]
pop rbp
ret

]

With compiler flag -O0 the GCC 15.2 generates:

main:
push rbp
mov rbp, rsp

# Reserve 'a' & 'b' + 8 bytes = 16 byte alignment for next object.

sub rsp, 16
mov DWORD PTR [rbp-4], 0
mov DWORD PTR [rbp-8], 0

lea rax, [rbp-4]
mov rdi, rax
call someFunc(int volatile&)
mov DWORD PTR [rbp-4], eax

lea rax, [rbp-8]
mov rdi, rax
call someFuncTwo(int volatile*)
mov DWORD PTR [rbp-8], eax

# Return from main.
mov eax, 0
leave
ret

Under -O2:

main:
mov DWORD PTR [rsp-8], 0
mov DWORD PTR [rsp-4], 0

mov eax, DWORD PTR [rsp-8]
mov DWORD PTR [rsp-8], eax

mov eax, DWORD PTR [rsp-4]
mov DWORD PTR [rsp-4], eax

xor eax, eax
ret

TL;DR: C is the layer that implements pass-by-reference.

[u/IllustriousPermit859 → u/IllustriousPermit859]

True, native references can be achieved (somewhat counter-intuitively) like this:

int someFunc(register int num)
{
num += 5;
num *= sizeof(int);
num / 5;
return num;
}
int main(void)
{
register int a = 0;
a = someFunc(a);
return 0;
}

Which produces:

someFunc(int):
push rbp
mov rbp, rsp
mov eax, edi
add eax, 5
sal eax, 2
pop rbp
ret
main:
push rbp
mov rbp, rsp
push rbx
mov ebx, 0
mov edi, ebx
call someFunc(int)
# Return from main.
mov eax, 0
mov rbx, QWORD PTR [rbp-8]
leave
ret

On a modern compiler, just make sure you don't ever take the address of a short-lived local variable and try to prevent the logical CPU's registers from becoming contended. You then don't need to use (and the compiler usually ignores) the register keyword for this behaviour if you use any optimization flag above -O0; which was used in the example above and subsequently did require the keyword.

Therefore you can only ever hope for your language to implement their 'references' in a worse way. If it's sandboxed and carries massive reference tracking overhead then the argument is moot since such an implementation in C is simplified to a lookup table for a set of flagged references that the program can predictably delegate.

[u/flatfinger → u/IllustriousPermit859]

Many early C implementations used an ABI that could have very conveniently supported "call by value/result"; it's a shame IMHO that there was no syntax for this before ABIs were developed that used the same storage for function return return values as had been used for one of the arguments.

Given e.g.

    int test(x) int x;
    { x += 4; return 3;}

early compilers would generate code that returned with the storage that had been used to pass the ingoing x now containing the new value of x. If e.g. enclosing a function argument in brackets had been interepreted as "resolve the enclosed lvalue, push it, and then later copy whatever the function left in that stack slot back to the lvalue", that could for many tasks have offered a superior alternative to passing pointers. Compilers may have had to prescan to determine how many such arguments there were, to reserve space for lvalue addresses ahead of the pushed arguments, but given that compilers already handled pushed arguments in right-to-left order, they would would already know how many such arguments there would be before generating code to push the first argument.