Why is NTuple generated for typedefs involving arrays?

[vrzh]

Using the latest code fe798d9 and the following C declarations:

typedef double mytype[1];  // no control over this typedef
mytype * get(void); // retrieve a mytype object
void f_bad(mytype a);
void f_good(double a[1]);

The Julia code generated is:

const mytype = NTuple{1, Cdouble}

function get()
    ccall((:get, libtest), Ptr{mytype}, ())
end

function f_bad(a)
    ccall((:f_bad, libtest), Cvoid, (mytype,), a)
end

function f_good(a)
    ccall((:f_good, libtest), Cvoid, (Ptr{Cdouble},), a)
end

In this case I am trying to understand why mytype results in an immutable NTuple being generated? With the above C code, it is possible to image getting a pointer to a mytype object from one function and passing it ("by reference" since it is really an array) into another function. But with the generated Julia code this seems impossible (please correct me if I am wrong?).

This seems to happen in the following code:

Clang.jl/src/generator/translate.jl

Lines 93 to 102 in fe798d9

	function translate(jlty::JuliaCconstarray, options=Dict())
	n = getNumElements(jlty.ref)
	elty = translate(tojulia(getElementType(jlty.ref)), options)
	return :(NTuple{$n,$elty})
	end
	function translate(jlty::JuliaCincompletearray, options=Dict())
	elty = translate(tojulia(getElementType(jlty.ref)), options)
	return Expr(:curly, :Ptr, elty)
	end

I am wondering what C code the first translate function would correspond to? I also saw the following comment:

Clang.jl/src/generator/codegen.jl

Lines 26 to 27 in fe798d9

	# array function arguments should decay to pointers
	# e.g. double f[3] => Ptr{Cdouble} instead of NTuple{3, Cdouble}

It sounds like it should apply for my example also?

[Gnimuc]

In this case I am trying to understand why mytype results in an immutable NTuple being generated?

I am wondering what C code the first translate function would correspond to?

If mytype is used as a type of a field member of a struct, it has to be a stack-allocated NTuple. If not, the layout of that struct will be incompatible with the one in C.

array function arguments should decay to pointers
e.g. double f[3] => Ptr{Cdouble} instead of NTuple{3, Cdouble}

In C, using const array type as function parameter types does not add any special restriction(e.g. the size) than a naive pointer type, the C compiler just does the decay implicitly, so here we do the same thing in Julia.

With the above C code, it is possible to image getting a pointer to a mytype object from one function and passing it ("by reference" since it is really an array) into another function.

It sounds like it should apply for my example also?

Yes, the current behavior is a bug, thanks for catching this!

I need to do a deeper check on that line, like if the type is a typedef, do the same check on the underlying type as well.

The expected result would be:

function f_bad(a)
    ccall((:f_bad, libtest), Cvoid, (Ptr{Cdouble},), a)
end

Note that, to use this function, mytype should be collected to a vector to get a valid pointer on the heap.

[vrzh]

Thanks, this is very helpful. BTW, should it be Ptr{mytype} instead of Ptr{Cdouble} in your expected result snippet above? I don't think it is necessary to expand the typedef.

In my case, I have the mytype appear both as a struct member and as a pointer in a struct member (not necessarily in the same struct), e.g.:

typedef struct {    // no control over this typedef
   mytype x;
   mytype * y;
   int n;
} mystruct;  

So I understand why NTuple is necessary now. To solve my problem, I just do pointer arithmetic in Julia:

for i = 1:q.n
    f(q.y + (i - 1) * sizeof(mytype))
end

This allows me to get a hold of Ptr{mytype} objects to pass to the function for modification. Small self-contained example here https://gist.github.com/vrzh/e338c886931503214e78b96aa0bd7c72

[Gnimuc]

@vrzh actually you could directly edit x or y without copying the whole mystruct.

There is an option for generating extra field access methods:

[codegen]
# generate getproperty/setproperty! methods for the types in the following list
field_access_method_list = ["mystruct"]

And to edit a Ptr{NTuple}, you could define something like these getter/setter functions which are very handy.

[Gnimuc]

should it be Ptr{mytype} instead of Ptr{Cdouble} in your expected result snippet above? I don't think it is necessary to expand the typedef.

I don't think so. mytype is indeed an array of doubles, nothing is expanded.

[vrzh]

Thanks, this is very useful to know.