From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7416 invoked by alias); 8 Oct 2013 17:30:24 -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 7406 invoked by uid 89); 8 Oct 2013 17:30:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: mail-pd0-f171.google.com Received: from mail-pd0-f171.google.com (HELO mail-pd0-f171.google.com) (209.85.192.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 08 Oct 2013 17:30:23 +0000 Received: by mail-pd0-f171.google.com with SMTP id g10so9014260pdj.16 for ; Tue, 08 Oct 2013 10:30:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sw4+/nHYFJHpm/w4X/Y7uN5smoaKcQ/KE9Kg7L7A7mM=; b=lBwilkuKvPFO++DckRHqmVE0XIkPf+F/DJiN6yl6gddOBS0AOi1NZL/pzRo3sEY/E5 8nikTknE3ocDcowxa2vFsbowk9Jn2uyT2c7SjzK9/wuARF+tPgRHHVYWfZaOUS9divl+ +KqpaqnirjrRXfwgju9lVQoqraHeH0CPAOZHCm83iKVrJjPqqDpVU1JnYNfih3t3Xhwg lzdcs+72gF8xHYH2AV3CT3omLH29JWWSnglTBeiE6goHa4zkKiqzD6PRK91zRhslq4vU 2n3KfFEtq/PeGphG5olOD7t5DxoSoP1Mr4Q3ti6/LmitD/+2xQ1qU0gFDEBopTgaHf7/ RNvg== X-Gm-Message-State: ALoCoQlJ8FyTas2WZyemZTMHSa6myTYvqmUhKXz1yfeMOKWiS8SRmb4cQFyPIkt62wHWEWQJABy0 MIME-Version: 1.0 X-Received: by 10.67.30.164 with SMTP id kf4mr4864334pad.13.1381253421621; Tue, 08 Oct 2013 10:30:21 -0700 (PDT) Received: by 10.70.96.228 with HTTP; Tue, 8 Oct 2013 10:30:21 -0700 (PDT) In-Reply-To: <20131008101354.43baeeeb@ygrex-mac> References: <20131008101354.43baeeeb@ygrex-mac> Date: Tue, 08 Oct 2013 17:30:00 -0000 Message-ID: Subject: Re: return value buffer malloc()'ed vs alloca()'ed From: Anthony Green To: Igor Bogomazov Cc: "libffi-discuss@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013/txt/msg00173.txt.bz2 Igor, You've hit one of the oddities of the libffi API. The result buffer needs to be the largest native integral type on your system. Use a 64 bit long for rc instead of mallocing the exact return type size. You can pass it into ffi_call as &rc and simply cast it to an int at the end. I just checked the docs and it's definitely not clear. I'll fix this. libffi is just a tiny bit faster when it can make this size assumption, but I agree that it isn't pretty. AG On Tue, Oct 8, 2013 at 1:13 PM, Igor Bogomazov wrote: > Hello, > > I've been trying to investigate valgrind warnings for a while and found > an undocumented feature, please let me know if it is well-known. > > What I did. > > I modified a code given in =AB2.2 Simple Example=BB so that return value > (rc), originally declared as (int), became an (int *)malloc(sizeof(int)) > so that it is resident in heap since that. Of cource, (&rc) replaced > with (rc) later in the code. > > What I get. > > valgrind complaints about =ABInvalid write of size 8=BB while =ABAddress > 0x55ec040 is 0 bytes inside a block of size 4 alloc'd=BB, it is exactly > that allocated (rc) buffer. > > Notes. > > Allocating buffer for the return value using alloca() does the trick and > makes valgrind silent. > > Further. > > I looked at x86/unix64.S, it is exactly the line: > movq %rax, (%rdi) > that causes the valgrind's warning (at .Lst_uint32) > > That is my question: is it necessary to allocate a buffer for the return > value with alloca() and never with malloc()? > > -- > Sincerely yours, > > Igor Bogomazov >