From: Anthony Green <green@redhat.com>
To: Chung-Lin Tang <cltang@linaro.org>
Cc: David Gilbert <david.gilbert@linaro.org>,
libffi-discuss@sourceware.org, Marcus.Shawcroft@arm.com
Subject: Re: [PATCH] Add variadic support
Date: Fri, 25 Feb 2011 19:02:00 -0000 [thread overview]
Message-ID: <m3wrkodjit.fsf@redhat.com> (raw)
In-Reply-To: <4D67AD61.9090106@linaro.org> (Chung-Lin Tang's message of "Fri, 25 Feb 2011 21:23:45 +0800")
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
next prev parent reply other threads:[~2011-02-25 19:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 15:41 Dr. David Alan Gilbert
2011-02-23 12:39 ` Anthony Green
2011-02-23 13:12 ` David Gilbert
2011-02-23 13:26 ` Chung-Lin Tang
2011-02-23 16:20 ` David Gilbert
2011-02-23 16:56 ` Chung-Lin Tang
2011-02-23 17:21 ` David Gilbert
2011-02-23 17:39 ` Chung-Lin Tang
2011-02-24 6:37 ` Chung-Lin Tang
2011-02-25 12:56 ` David Gilbert
2011-02-25 13:23 ` Chung-Lin Tang
2011-02-25 19:02 ` Anthony Green [this message]
2011-02-28 9:08 ` David Gilbert
2011-03-07 18:19 ` David Gilbert
2011-03-16 9:52 ` Chung-Lin Tang
2011-03-16 14:12 ` Anthony Green
2011-03-16 14:25 ` David Gilbert
2011-02-23 21:16 ` PowerPC failures (Was: [PATCH] Add variadic support) Anthony Green
2011-02-24 10:43 ` David Gilbert
2011-02-24 22:37 ` PowerPC failures Anthony Green
2011-02-24 22:41 ` Matthias Klose
2011-02-25 19:18 ` Anthony Green
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3wrkodjit.fsf@redhat.com \
--to=green@redhat.com \
--cc=Marcus.Shawcroft@arm.com \
--cc=cltang@linaro.org \
--cc=david.gilbert@linaro.org \
--cc=libffi-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).