From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kfqCL27fu18WTgAAWB0awg (envelope-from ) for ; Mon, 23 Nov 2020 11:12:30 -0500 Received: by simark.ca (Postfix, from userid 112) id B23151F0AB; Mon, 23 Nov 2020 11:12:30 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 31FBB1E58E for ; Mon, 23 Nov 2020 11:12:29 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E8597384A00F; Mon, 23 Nov 2020 16:12:28 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 5F11E384A00F for ; Mon, 23 Nov 2020 16:12:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F11E384A00F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 794E11E58E; Mon, 23 Nov 2020 11:12:25 -0500 (EST) Subject: Re: pushed: Add support for DWARF-based fixed point types To: Joel Brobecker References: <1604817017-25807-1-git-send-email-brobecker@adacore.com> <1605429345-78384-1-git-send-email-brobecker@adacore.com> <20201118034727.GF617116@adacore.com> <20201122140036.GA604842@adacore.com> <5e62ef60-93d7-ad52-4f9d-b23266ae4fc8@simark.ca> <20201123042711.GA967337@adacore.com> From: Simon Marchi Message-ID: <356a7864-d6aa-70ed-0444-7e19a4d5c2c9@simark.ca> Date: Mon, 23 Nov 2020 11:12:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201123042711.GA967337@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Language: tl Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2020-11-22 11:27 p.m., Joel Brobecker wrote: >> We pass mpz_export a buffer of 8 bytes (statically allocated in >> write_fp_test), but GMP decides it needs to write 16 bytes, hence the >> overflow. >> >> I tried to read the GMP doc, but I am familiar with its concepts, so I >> don't really understand if we are using the API correctly or not. > > I found the source of the problem, which was in a way subtle-enough > that you really have to pay attention to these details (which, > luckily, are handled automatically thanks to our minor C++-ification > of GMP in gmp-utils), and yet so obvious once you find it. > Attached is the patch that I will push later today (need to run RSN, > and don't want to make a mistake because I'm rushing). > > I think this error might be highlighting a weakness, though. I need > to investigate more, but I'm thinking it might be wise to add some > checks during export that the buffer size is large enough to fit > the value. In other words, I'm thinking of having our own > safe_mpz_export which double-checks the size of the buffer according > to the formula given by the documentation, and raises an error if > too small. > > The fact that GMP happily goes beyond the end of the buffer is > a bit unexpected, still. Maybe something to report to the GMP team. Ah, nice! The explanation in the commit message makes sense, thanks. And yes, please go wild adding assertions! Simon