public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com>
To: Bruno Haible <bruno@clisp.org>
Cc: libffi-discuss@sourceware.org
Subject: Re: small return types
Date: Sun, 22 Oct 2017 21:38:00 -0000	[thread overview]
Message-ID: <55d074869d04452303ab2c859a311130@mail.kylheku.com> (raw)
In-Reply-To: <5182570.xx5xnuqjYz@omega>

On 22.10.2017 13:33, Bruno Haible wrote:
> The new documentation says:
> 
>   +That is, in most cases, @var{ret} points to an object of exactly the
>   +size of the type specified when @var{cif} was constructed.  However,
>   +integral types narrower than the system register size are widened.
> 
> Which is not useful, because the point of using a library such as 
> libffi
> is to NOT NEED TO KNOW about the ABI, about the width of system 
> registers
> etc.

Unfortunately, that's the library interface that a test suite has
to exercise, and not the ideal one that we would like to exist in
it place.

This cannot be fixed without breaking correctly implemented programs
which follow the scheme.

Using the API right is slightly ugly but not a major complication.

My FFI implementation experience shows that it can be absorbed in a
design which didn't anticipate the issue at all, and in a reasonably 
localized
way which hides it from the higher levels.

The register size is abstracted by the ffi_arg type; applications don't
have to depend on how specific sizes in specific ways.

  reply	other threads:[~2017-10-22 21:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-21 18:31 test results on many platforms Bruno Haible
2017-10-22  8:12 ` Matthias Klose
2017-10-22 14:58   ` Bruno Haible
2017-10-22 18:28 ` Kaz Kylheku (libffi)
2017-10-22 20:33   ` small return types Bruno Haible
2017-10-22 21:38     ` Kaz Kylheku (libffi) [this message]
2017-10-25  5:18     ` Tom Tromey

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=55d074869d04452303ab2c859a311130@mail.kylheku.com \
    --to=382-725-6798@kylheku.com \
    --cc=bruno@clisp.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).