In C, filling a struct-shaped bucket with a struct-shaped value is exactly what happens when you initialize, assign to, or pass an argument to a struct-typed variable. Early C severely restricted when you could do such things, but that’s always how it worked when it was allowed, and in modern C it’s allowed almost everywhere you’d want it to be. If you want to pass around a pointer in C, you have to be explicit on both ends—use a pointer-to-struct-typed variable, and use the & operator on the value (and then you have to use the * operator to do anything with the pointer variable). And the right way to think about it is not reference semantics, but filling a pointer-shaped bucket with a pointer-shaped value. (Or, actually, not just “pointer” but specifically “pointer to some specific type”; you can’t portably stick a pointer-to-nullary-int-function value in a pointer-to-double value.)

And this is key to the whole notion of lvalue semantics, where variables (among other things) are typed buckets with identity for storing values (that are just bit patterns), as opposed to namespace semantics, where variables (among other things) are just names for typed values with identity that live wherever they want to live. After `a=b` in a namespace language, `a is b` is true, because a and b are two names for the one value in one location; in an lvalue language, there usually is no such operator, but if there were. `a is b` would still be false, because a and b are two distinct locations that contain distinct copies of the same value, because what `a=b` means is filling the a bucket with the value in the b bucket. (In fact, in C., even `a==b` might not be true if, say, `a` is an uint16 variable and b is a uint32 variable holding a value over 65535.)