Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: WIP: start to remove pointer(::Array) & friends #6618

Closed
wants to merge 1 commit into from

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Apr 24, 2014

I think the pointer and convert(::Ptr,Array) functions make it altogether too easy to make unmanaged pointers. Leading to unsafe situations such as the following:

julia> type X
       x::Ptr{Void}
       end

julia> X([1,2,3])
X(Ptr{Void} @0x00007ffc644a6e40)

Furthermore, it encourages ccall(:a, Ret, (Ptr{T},), pointer(T)), which is identical to the call without the pointer, but is potentially missing a GC root.

However, attempting to remove the pointer function from base reveals a rather heavy dependence on this function. A few of the usages of the function in the blas libraries are there to compute an offset pointer. However, many or most of these usages seem largely unnecessary.

@vtjnash
Copy link
Member Author

vtjnash commented Apr 24, 2014

avoiding the silent automatic conversion that now is the default, as shown in my example code, and generally discouraging passing around arrays as pointer in julia code

@JeffBezanson
Copy link
Member

Aside from it being a hugely breaking change, I can see an argument for removing convert(Ptr, ...) so it doesn't happen implicitly. You would have to call pointer, like how convert only does safe conversions for numbers but int(x) implicitly rounds. cconvert could then have 1 (or a small number) of definitions that use pointer. This would also be a case to use coerce, which might replace the int(x) family of functions. That would make it fairly clear what you need to overload (though still not as clear as it is now).

@timholy
Copy link
Member

timholy commented Apr 24, 2014

Is there stronger motivation for this change than I'm aware of? While I know it's dangerous, I would shed a tear if this went away, at least if it happens before we have fast array views.

One way I'm using pointer is to provide views of tiled arrays, all allocated with contiguous memory. Once we get fast views (that also support bounds-checking in a nice way), I won't need that, but currently

A = Array(Float64, 8, 8, 4, 4)
Atile = Array(Matrix{Float64), 4, 4)
for j=1:4, i=1:4
    Atile[i,j] = pointer_to_array(pointer(A)+64*sizeof(eltype(A))*(4*(j-1)+1), (8,8), false)
end

seems to be the best way to get the features I want.

@vtjnash vtjnash deleted the jn/array_ptr branch August 11, 2014 22:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants