From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41990 invoked by alias); 22 Oct 2017 20:33:12 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 41455 invoked by uid 89); 22 Oct 2017 20:33:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=CIF, cif, 1990, 3.2.1 X-HELO: mo4-p00-ob.smtp.rzone.de Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de) (81.169.146.216) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 22 Oct 2017 20:33:09 +0000 X-RZG-AUTH: :Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqf0zZRW X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de (dslb-088-068-032-102.088.068.pools.vodafone-ip.de [88.68.32.102]) by smtp.strato.de (RZmta 42.8 DYNA|AUTH) with ESMTPSA id I0b719t9MKX5QNm (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sun, 22 Oct 2017 22:33:05 +0200 (CEST) From: Bruno Haible To: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> Cc: libffi-discuss@sourceware.org Subject: Re: small return types Date: Sun, 22 Oct 2017 20:33:00 -0000 Message-ID: <5182570.xx5xnuqjYz@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-96-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <2437301.0N14NqkuRT@omega> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2017/txt/msg00025.txt.bz2 Hi Kaz, Changing the subject, since we're talking about https://github.com/libffi/libffi/issues/361 https://github.com/libffi/libffi/issues/362 https://github.com/libffi/libffi/issues/368 https://github.com/libffi/libffi/issues/369 > I suspect that some of your ffi_call bug reports on 64 bits may be > invalid. > > The return value on 64 bits, of small types, requires special treatment > due to known quirk/design flaw in the API. It was originally not > documented, > and then it was just documented as is. The way your code is doing it > is how it *should* be, but isn't. The 3.2.1 documentation says: -- Function: ffi_status ffi_prep_cif (ffi_cif *CIF, ffi_abi ABI, unsigned int NARGS, ffi_type *RTYPE, ffi_type **ARGTYPES) This initializes CIF according to the given parameters. ... RTYPE is a pointer to an 'ffi_type' structure that describes the return type of the function. *Note Types::. Types: 'Libffi' provides a number of built-in type descriptors that can be used to describe argument and return types: ... 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. > This situation bears some resemblance to promotion in the C language! But this resemblance is not a justification for libffi's behaviour, because 1) 'char'. 'unsigned char' etc. are considered as valid return types of functions (and different from 'int') since ANSI C, 1989/1990. 2) C does not do promotion from 32-bit integer types to 64-bit integer types. > Naively written code will appear to work fine on little endian 64 bit, No, the bug https://github.com/libffi/libffi/issues/368 also affect some little-endian platforms. Bruno