From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id 31AF83858D33 for ; Sat, 20 Mar 2021 23:57:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 31AF83858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=moxielogic.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=green@moxielogic.com Received: by mail-il1-x135.google.com with SMTP id z9so11471546ilb.4 for ; Sat, 20 Mar 2021 16:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moxielogic-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4kYTMdRGu4epBnZYrLJdRY+rDitgto515R/LVy97FGY=; b=Ox3P3Q4U00ozDRzRmMn02hCnbyf6aFHGHWuzztxUMNErNrdGDB7otJ2lrd9zvCz7Ij u7tQBYGdf1LzfD785sqYXoOUwtE0Ar0XO/UYNTvspR0qcPXafmt/UfODmeUMe412YtAV 3We82YO9v069q7NmjZ/iZb2z651kmbu+yBDeAYmRzOEYl40NMss48S8yEsyw3vs2lJGO BkBweDoLZPWBdO77bUPHHF9v6HNKNq+C371WIP7tia4aA1T71XbAug/VXSZA2GIO+ppG hgXfZoRORPsZn/2Jox0svNHiC7htzZkMboiv5NLdHeOvqJsSGwLA8d0jW+LHPghT3Iqg cG7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4kYTMdRGu4epBnZYrLJdRY+rDitgto515R/LVy97FGY=; b=PWmkqQ5TcoA/7Tdo8zlU4EQ6brsVkKDy384v+raGPBTOgWrX7PfU0pl91dVHs8TN5J vmbU+3J1aO4VCrk+3cVNZlVsuzv1Ck16pgoiQ8AAtoxdbKonSaOdo3oDMAU4/I99jmhL 8WakFFGbECpcOmpXyPqUlLetsUCwTvqMnl06KCAjjBSGhHcC5NxV3umHzWNHYvFDIv7m CrwA8Itx5K3AdvITTk3Ivfb8thpepOQsqPm/geZbWqEZ+FsKXv6bg14ZOrMuQJGZlCII 6S5v7jcs6tyex2LEBnVLXg0+e2pfp6FZfAUJrcJdC/14vwTSb5VWzQ0pr4cw9LkJzzfJ dZLw== X-Gm-Message-State: AOAM530pnnYw1ngeAUl5ylZ3PYnOVhDD51MzLCFPuwG0ce8GvHovLavO GXwHFUKvVLo+8xmwtrl0onQOgNqv65DcxF3o8ncwyg== X-Google-Smtp-Source: ABdhPJz280leVyUXFOhPhOa6CxfWRuiR5wpKDp7lUbjzxzgAt1UIYakrxLugxz9fsvaVoFuvtbPHPjjbrkroxM54554= X-Received: by 2002:a05:6e02:1286:: with SMTP id y6mr7170511ilq.270.1616284628704; Sat, 20 Mar 2021 16:57:08 -0700 (PDT) MIME-Version: 1.0 References: <00aed94e-6f76-f6d7-9878-a3eb50dce543@163.com> <7c8729d8-d10e-cdb8-5518-e2f82ccbe141@redhat.com> <71f0c5ea-e3b7-176e-a0a1-29dceeff69b9@redhat.com> In-Reply-To: From: Anthony Green Date: Sat, 20 Mar 2021 19:56:57 -0400 Message-ID: Subject: Re: How to call 'printf' using libffi? To: Andrew Haley Cc: libffi-discuss X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 23:57:11 -0000 It's worth noting that JNA, one of libffi's big users, does the float-to-double promotion at their layer. https://github.com/java-native-access/jna/issues/463 Ruby's FFI does the same thing: https://github.com/ffi/ffi/blob/6d14c0a9107c0d5febb3bf92a60d2581e768fa2f/ext/ffi_c/Variadic.c This is making me feel more comfortable about returning an error on float varargs. (I've change my mind about aborting) AG On Sat, Mar 20, 2021 at 6:40 PM Anthony Green wrote: > 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 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://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >>