Ccall and cconvert for Ptr{T}

Just a quick question about ccall and cconvert. From the manual I know that

ccall((:foo, "libfoo"), Void, (A, ), x)

will result in a call to

ccall((:foo, "libfoo"), Void, (A, ), unsafe_convert(A, cconvert(A, x)))

But what about the following:

ccall((:foo, "libfoo"), Void, (Ptr{A}, ), x)

Will this result in a call to

ccall((:foo, "libfoo"), Void, (Ptr{A}, ), unsafe_convert(Ptr{A}, cconvert(A,x)))

or is there something else going on?

Here is how this came up. I have types A and B for which I define convert(Type{A}, ::B). Because of a typo I wrote

ccall((:foo, "libfoo"), Void, (Ptr{A}, ), x)

and it did not throw an error.

No, it’ll be

ccall((:foo, "libfoo"), Void, (Ptr{A}, ), unsafe_convert(Ptr{A}, cconvert(Ptr{A},x)))

There’s nothing special about Ptr.

Sorry, I think I wrote something wrong. I defined convert(Type{A}, ::B) and then the following worked

ccall((:foo, "libfoo"), Void, (Ptr{A}, ), &x)

It does not throw a method error. This is what surprised me.

That lowers to a different set of functions that are not documented since it’ll be deprecated. You can figure out all these by looking at code_lowered of the ccall and use code_typed to see which methods are called.

Thanks a lot and sorry for the confusion. Is there a roadmap for deprecating & in ccall? This has been called “deprecated” since 0.4, but I have not seen a deprecation warning so far. It is also used extensively in Base.MPFR and Base.GMP.

The function is fully covered by the Ref equivalent but we need better optimizations in type inference to make them perform the same. There isn’t currently a timeline for that. (It’s high, though not highest, on my todo list and I can’t say for others).