From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2ILqBdUFs1/jbwAAWB0awg (envelope-from ) for ; Mon, 16 Nov 2020 18:05:57 -0500 Received: by simark.ca (Postfix, from userid 112) id 148F71F08B; Mon, 16 Nov 2020 18:05:57 -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=unavailable 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 9A1F81E552 for ; Mon, 16 Nov 2020 18:05:56 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3C2C1385780A; Mon, 16 Nov 2020 23:05:56 +0000 (GMT) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by sourceware.org (Postfix) with ESMTPS id 9AFCF385780A for ; Mon, 16 Nov 2020 23:05:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9AFCF385780A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wm1-f50.google.com with SMTP id h2so1108597wmm.0 for ; Mon, 16 Nov 2020 15:05:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=D7z3Bavsv+N5tKrkS7wFJn7DHa3ij4dBtDZ53C5+HR4=; b=eKRLxRKp12DBIUmGXuzcBaII1zzweKfAt9YICHh1PfQ08t2rFCoBZsB9Xk1WrnRxnS ceyyqhAFhi/tSW+B2Wlg4zpFekFwR8XVAhsSV2ZwZw+kr19Sf8BgvSmdcvx7Sig1gJVv PSNSbCOUCubKvnAxZQhCM8xQJqs5Z3rLCQrrR4zyqga96JlvaCQhKXlfwNR7qehd4To4 /tyD+qrJXpChwYMqPjOMNkvbnMZykV49c3zre5KqD8mlRZPOjNp1ZANHQCA+/DWujkpJ nw8B4rUaSq/eW1ZiRtJcGrMmnv84kY0FKiqtPBFl6XELgxfry7RDQPSTrUeGNBFw8Ibf dM9A== X-Gm-Message-State: AOAM530fnr6TvvzOm/KQsllTtyqRhjTn5ZgRpxGh9qeSSRxHmd7gNoDG kqrFLAywej/r7WKVtfB3wvUA3FusJ4mqDQ== X-Google-Smtp-Source: ABdhPJxjHYQgn9fQei5ZXJtwYjq0Y1cU/szzxxRG7AXc5oAPlgxEkbgX6G8U5TaXkiB43rNpLuQGiQ== X-Received: by 2002:a7b:cb09:: with SMTP id u9mr1152135wmj.49.1605567952147; Mon, 16 Nov 2020 15:05:52 -0800 (PST) Received: from ?IPv6:2001:8a0:f91f:e900:642f:5bb0:6cba:b1bd? ([2001:8a0:f91f:e900:642f:5bb0:6cba:b1bd]) by smtp.gmail.com with ESMTPSA id a12sm24308613wrr.31.2020.11.16.15.05.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Nov 2020 15:05:51 -0800 (PST) Subject: Re: [RFA 2/6] gmp-utils: Convert the read/write methods to using gdb::array_view To: Simon Marchi , Joel Brobecker , gdb-patches@sourceware.org References: <1604817017-25807-1-git-send-email-brobecker@adacore.com> <1605430184-81335-1-git-send-email-brobecker@adacore.com> <1605430184-81335-3-git-send-email-brobecker@adacore.com> <9fcbb9da-97d9-c0b2-a5b5-39f114fbe819@simark.ca> From: Pedro Alves Message-ID: <14f04e1f-ab01-8675-533f-24aaaa466966@palves.net> Date: Mon, 16 Nov 2020 23:05:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9fcbb9da-97d9-c0b2-a5b5-39f114fbe819@simark.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 11/16/20 12:52 AM, Simon Marchi wrote: > On 2020-11-15 3:49 a.m., Joel Brobecker wrote: >> This commit changes the interfaces of some of the methods declared >> in gmp-utils to take a gdb::array_view of gdb_byte instead of a >> (gdb_byte *, size) couple. >> >> This makes these methods' API probably more C++-idiomatic. >> With the way things are structured, this change introduces a minor >> extra complication at the point of call of these methods, since >> the data available there is not in the form of an array_view, >> and thus the array_view needs to be constructed on the spot. > > I'd suggest using gdb::make_array_view (ptr, len) instead of the > array_view constructor. This way, you don't need to specify the > template type, it's automatically deduced, so it's a bit less verbose. > Otherwise, LGTM. Note gdb::make_array_view is only necessary if the type of len is not size_t. If it is size_t, then the shorter "{ptr, len}" works. As an illustration: --- i/gdb/unittests/gmp-utils-selftests.c +++ w/gdb/unittests/gmp-utils-selftests.c @@ -95,7 +95,7 @@ gdb_mpz_as_integer () template void -store_and_read_back (T val, int buf_len, enum bfd_endian byte_order, +store_and_read_back (T val, size_t buf_len, enum bfd_endian byte_order, gdb_mpz &expected, gdb_mpz &actual) { gdb_byte *buf; @@ -109,8 +109,7 @@ store_and_read_back (T val, int buf_len, enum bfd_endian byte_order, mpz_set (actual.val, expected.val); mpz_sub_ui (actual.val, actual.val, 500); - actual.read (gdb::array_view (buf, buf_len), - byte_order, !std::is_signed::value); + actual.read ({buf, buf_len}, byte_order, !std::is_signed::value); }