Re: [PATCH] Add variadic support

[Anthony Green <green at redhat dot com>]

Chung-Lin Tang <cltang@linaro.org> writes:

> This might sound a bit hackish, but considering the usual realistic
> number of fixed args, we should be able to splice the cif->flags word:
> magic value in upper 16-bits, while lower half contains the passed-in
> nfixedargs.
>
>> I think the way to move it in the direction of what you're suggesting is:
>>    1) as per my code have an ffi_prep_cif and ffi_prep_cif_var that
>> both call ffi_prep_cif_core
>>    2) Explicitly pass ffi_prep_cif_core the extra parameter rather
>> than storing it in cif.
>>    3) Still keep an ifdef to say if the backend has explicit variadic
>> support, if that ifdef is set
>>        then ffi_prep_cif_core will call ffi_prep_cif_machdep_var when
>> appropriate.
>>    4) ffi_prep_cif_machdep_var will get the argument count passed as
>> explicit parameters,
>>        then it can process them as it feels fit including storing them
>> in an EXTRA_CIF_FIELD
>>        if the backend wants to.
>
> Yeah, I think that's fine. My attempt was to avoid the extra #ifdefs and
> extra backend machine-dependent function; if that's unavoidable, then I
> think this is fine.
>
> Anthony, as maintainer, do you have any ideas?
>

I always envisioned it working this way:

  - add a new FFI type, say FFI_TYPE_VARIADIC
  - users would just append this to the array of types when they
    create a cif for a variadic function

No new API is required in this case.  Wouldn't this work?

AG