avoid implicit copy in ptr::addr_of()

[dram]

I wonder if there is any use for ptr::addr_of() to return address of a temporary copied version of its argument, but it seems a bit annoying. E.g. for following code, different address will be printed.

fn main() {
 let foo = 1;

 log(error, addr_of(foo));
 log(error, addr_of(foo));
}

Use following version of addr_of instead, the address will be consistent.

fn addr_of<T>(&val: T) -> *T { ret ptr::addr_of(val); }

And a real world example:

fn get_elem(mixer: snd_mixer, name: str) -> snd_elem {
 let sid = null();

 asound::snd_mixer_selem_id_malloc(addr_of(sid));

 asound::snd_mixer_selem_id_set_index(sid, 0);

 as_c_str(name) {|buf|
 asound::snd_mixer_selem_id_set_name(sid, buf);
 }

 ret asound::snd_mixer_find_selem(mixer, sid);
}

asound::snd_mixer_selem_id_malloc() will allocate a buffer and assign the address to sid。But as sid is implicit copied, sid remains 0 after this function call.

Can ptr::addr_of() be defined as always pass by reference to avoid implicit copy?

[nikomatsakis]

This is the current behavior. addr_of<T>(t: T) will pass by reference because type variables (T) are passed by reference by default (as are scalars and non-unique pointers).

[marijnh]

What you were seeing here -- with the two different addresses being shown -- is produced by the fact that an immediate value that's not assigned to does not get spilled to the stack. So the calls were doing their own spilling to be able to pass it by reference, each producing a different address. Your & approach helped because passing something by mutable reference counts as assigning to it, forcing it to be spilled.

This is all rather confusing. We'll soon be overhauling the way function argument passing works, and in the process will have to rethink the way addr_of takes its arguments as well.

[brson]

This does seem like a real issue. C doesn't exhibit this behavior, does it?

[marijnh]

C forces locals to be stack-allocated when you take their address. I'm going to make addr_of something that the compiler knows about as part of the work on #1981. I can take a stab at properly fixing this too.

[nikomatsakis]

Regions let you take the address using the & operator, also.

[marijnh]

That actually sounds like a much better approach. So I guess we'd have addr_of take a reference to some thing? Or do you think we should make a variant of the & operator that returns an unsafe pointer right away?

[graydon]

I think &foo as *bar ought to be an unsafe (but legal) operation, and we can parcel it up as addr_of<T> if someone feels the cast is too clunky.