You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've seen code written in use (e.g. the code deleted by JuliaInterop/JavaCall.jl@62b7c94#diff-8e308bc5fa4175394c000f10db4abd8cL257) that treats Variadic arguments as the same as regular arguments in a ccall. This was valid in x86, but it violates the platform ABI of x86_64 (a somewhat minor deficiency) and completely ignores the platform ABI of Win64 (and is thus a very bad idea).
Currently the syntax only allows one, compile-time, argument type (T1, T2, T3...), but more flexibility may be necessary, although I don't know how I would express it:
perhaps just allow more args than ccall parameters, and auto-detect the types of the remaining parameters?
similar idea, but the remaining parameters must be tuples of (Type, value)?
???
The text was updated successfully, but these errors were encountered:
I've seen code written in use (e.g. the code deleted by JuliaInterop/JavaCall.jl@62b7c94#diff-8e308bc5fa4175394c000f10db4abd8cL257) that treats Variadic arguments as the same as regular arguments in a ccall. This was valid in x86, but it violates the platform ABI of x86_64 (a somewhat minor deficiency) and completely ignores the platform ABI of Win64 (and is thus a very bad idea).
Currently the syntax only allows one, compile-time, argument type
(T1, T2, T3...)
, but more flexibility may be necessary, although I don't know how I would express it:(Type, value)
?The text was updated successfully, but these errors were encountered: