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

syntax for handling variadic ccalls correctly for complex cases #5270

Closed
vtjnash opened this issue Dec 31, 2013 · 2 comments
Closed

syntax for handling variadic ccalls correctly for complex cases #5270

vtjnash opened this issue Dec 31, 2013 · 2 comments
Labels
design Design of APIs or of the language itself kind:bug Indicates an unexpected problem or unintended behavior

Comments

@vtjnash
Copy link
Sponsor Member

vtjnash commented Dec 31, 2013

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:

  1. perhaps just allow more args than ccall parameters, and auto-detect the types of the remaining parameters?
  2. similar idea, but the remaining parameters must be tuples of (Type, value)?
  3. ???
@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Jul 15, 2015

see #6661 julep

@StefanKarpinski StefanKarpinski added design Design of APIs or of the language itself and removed needs decision A decision on this change is needed labels Sep 13, 2016
@vtjnash vtjnash closed this as completed Jan 24, 2023
@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Jan 24, 2023

@ccall now implements this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design of APIs or of the language itself kind:bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

2 participants