introduce va_list

[vtjnash]

proposal: introduce va_list type for ccall / cfunction

usage:

ccall(:abc, Int, (A, B, va_list{(C,D,E)}), a,b,c,d,e)
# int abc(A, B, ...) {}
# {
# abc(a,b,c,d,e);
# }

va = va_list(c,d,e)
ccall(:abc, Int, (A, B, va_list), a, b, va)
ccall(:abc, Int, (A, B, va_list{()}), a, b, va)
# int abc(A, B, va_list) {}
# {
# va_list ap;
# va_start(ap, X);
# abc(A,B, ap);
# }

definitions:

immutable va_list{T<:Tuple}
  # opaque
  va_list(args...) = (T == () ? new(magic...) : error("cannot construct a typed va_list"))
end
va_list(values...) = va_list{()}(values...)

thoughts? improvements? should I make a pull request?

[JeffBezanson]

I'm not sure a va_list can or should be a constructable, first-class object. The only reason to have a va_list object is if you get one via a cfunction callback and want to pass it to another C function taking a va_list. The special () value is kind of strange.

I guess there are C compilers where the first case is different from

ccall(:abc, Int, (A, B, C, D, E)}), a,b,c,d,e)

?

[vtjnash]

I guess there are C compilers where the first case is different from

yeah, but nobody uses them, just x86_64 ABI, Win64 ABI, and newer ARM specifications

That special value should be mostly invisible to the user -- the idea is to only allow the user to construct untyped versions, but to have the type parameter only for ccall. since va_list and va_list{(...)} have different meanings in ccall, this is enforced by only allowing construction of one of them.

The parser would need to be altered to recognize va_list{(...)} and apply cconvert correctly.

I was looking at making va_list constructable objects for passing to c functions that take that argument. Deconstructing them could be handled through llvm intrinsics, but it wasn't on my priority list.

[timholy]

Rather than squashing both meanings into a single va_list, what about va_types and va_args?

[Gnimuc]

Any update on this? C interop in Julia would be perfect if we could support this.

[KristofferC]

Perhaps can be closed. Or only after #32748 is merged?

[vtjnash]

va_list is only tangentially related to varargs, although the exact details of the proposal above need to be revisited.