public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Anthony Green <green@moxielogic.com>
To: Andrew Haley <aph@redhat.com>
Cc: libffi-discuss <libffi-discuss@sourceware.org>
Subject: Re: How to call 'printf' using libffi?
Date: Sat, 20 Mar 2021 18:40:06 -0400	[thread overview]
Message-ID: <CACxje59g9JirgoTxohQOHrP+At5L-JypHmyJZ7GTtd6cCmSqRA@mail.gmail.com> (raw)
In-Reply-To: <71f0c5ea-e3b7-176e-a0a1-29dceeff69b9@redhat.com>

It turns out there are problems with ffi_prep_cif_var().  One issue is that
libffi doesn't promote floats to doubles for varargs, like most C hackers
expect.  There was a bug filed against that recently:
https://github.com/libffi/libffi/issues/608
Should libffi do the promotion, or leave it as an exercise to the
developer?  Right now I'm thinking that it should simply abort in
ffi_prep_cif_var() if passed any of ffi_type_float, ffi_type_*short, or
ffi_type_*char and require that the caller handle promotions and only pass
pointers, structs, doubles, ints or larger, as it seems that we're not
promoting short integer values either.  If I pass a very long list of
varargs that end in a sequence of ffi_type_schar, for instance, the callee
doesn't find the right values in the right stack locations.  So maybe we
shouldn't allow that in the first place.

I'm interested in opinions.

Thanks,

AG


On Fri, Mar 19, 2021 at 7:43 AM Andrew Haley <aph@redhat.com> wrote:

> On 3/19/21 11:01 AM, Anthony Green wrote:
> >>>   ffi_prep_cif_var(&cif, FFI_DEFAULT_ABI, 1, 3, &ffi_type_sint,
> >> arg_types);
> >>
> >> Surely that only works if a varargs call uses the same ABI as a normal
> >> call. They don't always,
> >>
> > I'm using the '_var' variant of ffi_prep_cif that takes this into
> account.
>
> Aha! Missed it.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>

  reply	other threads:[~2021-03-20 22:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 14:04 ShaJunxing
2021-03-18 15:25 ` Anthony Green
2021-03-19  2:08   ` ShaJunxing
2021-03-19  2:36     ` Kaz Kylheku (libffi)
2021-03-19  3:09       ` ShaJunxing
2021-03-19 10:13   ` Andrew Haley
2021-03-19 11:01     ` Anthony Green
2021-03-19 11:43       ` Andrew Haley
2021-03-20 22:40         ` Anthony Green [this message]
2021-03-20 23:56           ` Anthony Green
2021-03-22 10:36             ` Andrew Haley
2021-03-19 11:26     ` Jarkko Hietaniemi
2021-03-19 11:33       ` 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=CACxje59g9JirgoTxohQOHrP+At5L-JypHmyJZ7GTtd6cCmSqRA@mail.gmail.com \
    --to=green@moxielogic.com \
    --cc=aph@redhat.com \
    --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).