Dissallow pointer_from_objref on immutable values

[ivarne]

See discussion in https://groups.google.com/forum/#!topic/julia-dev/F9PggSikPW8 that requests an issue to track this.

@vtjnash

this is not C – variables don't have first-class memory addresses (also, pointer_from_objref on a immutable returns a semi-random number that was correlated at some point in the past with the value).

@StefanKarpinski

This should really not be allowed: calling pointer_from_objref on an immutable should be an error.

[StefanKarpinski]

I had also argued that this should be folded into the pointer function. The counterargument was that the hideous name of pointer_from_objref somehow made it safer. (Perhaps we should call it ____pointer__from_objref_______ instead?) Removing the ability to call it on objects that don't actually have a valid pointer value, would reduce the danger, making this usage no more or less dangerous that taking a pointer to any other gc-able value, such as an array.

[yuyichao]

The counterargument was that the hideous name of pointer_from_objref somehow made it safer.

No, my argument from the very beginning is the ambiguity. There are objects that have totally different meanings for pointer and pointer_from_objref. One of them can be overloaded (pointer) and the other not. Also, as we get better support for the unsafe_convert interface, pointer will be less and less needed for user code. However, low level function like pointer and pointer_from_objref are still useful for implementing unsafe_convert.

[StefanKarpinski]

There are objects that have totally different meanings for pointer and pointer_from_objref.

For example?

[yuyichao]

Arrays

[yuyichao]

There are objects that have totally different meanings for pointer and pointer_from_objref.

In general, any object that is related to any buffer has this problem (in fact, otherwise, pointer doesn't have any meaning..). This include other types like strings too.

However, this is the most relevant for arrays since other types that has this property should generally move away from extending pointer and use Ref and unsafe_convert instead, but as long as we still have an array like type with possibly non-inline storage (i.e. different from the only meaning of pointer_from_objref), we always need a function to get that storage in order to implement the higher level interface (or we could of course just use jl_array_ptr and jl_value_ptr in the implementation and not allowing non-base code to use them directly).

[yuyichao]

More on topic for this issue, I very occasionally find it useful to check what addresses julia may allocate for an isbits type so it would be nice if this is still possible (I can of course use a debugger but that's more complicated).

Since we now have @pure I think the easiest way to implement this is to add a check in the julia implementation while leaving jl_value_ptr do whatever it used to do.

[StefanKarpinski]

I'm ok with maintaining separate functionality for getting the object address and the "data address", but the current arrangement is clunky, inconsistent and ugly. It would be better to write something like pointer(Ref(x)) to get a pointer to x as an object. That has the benefit of working for immutables too.

[StefanKarpinski]

Of course, to avoid GC issues, you'd want to write something more like this:

r = Ref(x)
p = pointer(r)
# do something with p while holding onto r

[yuyichao]

FWIW, unsafe_convert of RefValue is implemented with pointer_from_objref. If the proposal is to unexport and deprecate pointer_from_objref and use Base.unsafe_convert(Ptr{Void}, Base.RefValue(x)) instead then I'm totally fine with it...

[yuyichao]

FWIW, unsafe_convert of RefValue is implemented with pointer_from_objref

And btw this is exactly what I mean by we still need the low level bits with clear meanings to implement these and that we could just deprecate both and always use the Ref unsafe_convert functions.

[ihnorton]

Bump for triage? Would be nice to firm up the API here before 1.0.

https://discourse.julialang.org/t/working-on-spidev-h-and-spidev-c-translation/6479/46?u=ihnorton

[JeffBezanson]

I think all we should do here is disallow pointer_from_objref on an object that might not be heap-allocated.

[vtjnash]

I think all we should do here is disallow pointer_from_objref on an object that might not be heap-allocated.

Post #22684, that's all of them :)

[yuyichao]

I think the right condition is still if the object is allowed to be reboxed, which is all immutable objects.

We'll also need to document that accessing the type tag with this pointer is not allowed.