Ccall and cconvert for Ptr{T}

General Usage
1

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

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

and it did not throw an error.

2

No, it’ll be

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

There’s nothing special about Ptr.

4

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

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

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

5

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.

6

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.

7

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).