From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id 26DBD385275E for ; Mon, 13 Jun 2022 14:00:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 26DBD385275E Received: by mail-pj1-x102d.google.com with SMTP id o33-20020a17090a0a2400b001ea806e48c6so6016164pjo.1 for ; Mon, 13 Jun 2022 07:00:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kbML3gqEPvKFmA6eFrkEulbmogP1w0hg0IC2QBkoFqY=; b=Te66AWDE68e2rYVEVZYml6EkkAtY5InOX8fHRYfOLoRf3Oie7ds7rm+hpQzCAfq4UU nEM7tSzX1IYzQ1G/aWMSIAu9oVNnB/HrHQcZLaMEctZIyS9DD8h+cSsvTaPY1Q2h+P02 Sdur3mtQpqkfBxw0OQ7dgOZ9MOqWESmIv6cuAiWxV0JW95h4xvvMWvUi2pR2UDTaJIii vnGxBidLuDby+ZSh5+Eapl3M/btxJkZwk6aWbvs3PV8wK9mWQpix8guYFnPrfyKL8jR5 j7VPm0QCz/097qED7+4OIT/UBns9vzSd7WpAmgpiTnR/EI1RZR6nop7fuDeClSa2si/X WScA== X-Gm-Message-State: AOAM531I374i1i8bVmq2kunvwerpLms8W95XXJaJ5DuqcEtbLJcRpAwA QimuKLho3yAvk+oJxsB7W3BgTRPUsZroNKCEwMk= X-Google-Smtp-Source: ABdhPJxezhILpxzfSu2EfU1Gus6sLFw5UPWlitsiRYZ0knDE9mvCUJJMYGJEatckzqh1DfQkwktPQKnUqPMsPQp0Rlc= X-Received: by 2002:a17:90b:2349:b0:1e3:34f9:87e8 with SMTP id ms9-20020a17090b234900b001e334f987e8mr15938008pjb.217.1655128815039; Mon, 13 Jun 2022 07:00:15 -0700 (PDT) MIME-Version: 1.0 References: <6fd28ca0-2af4-7335-18d3-31036dea7a4f@suse.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 13 Jun 2022 06:59:39 -0700 Message-ID: Subject: Re: [PATCH 4/4] x86: replace global scratch buffer To: Jan Beulich Cc: Binutils , Andrew Burgess Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3019.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2022 14:00:21 -0000 On Fri, Jun 10, 2022 at 6:36 AM Jan Beulich wrote: > > With its movement to the stack, and with the subsequent desire to > initialize the entire instr_info instances, this has become doubly > inefficient. Individual users have better knowledge of how big a buffer > they need, and in a number of cases going through an intermediate buffer > can be avoided altogether. > > Having got confirmation that it wasn't intentional to print memory > operand displacements with inconsistent style, print_displacement() is > now using dis_style_address_offset consistently (eliminating the need > for callers to pass in a style). > > While touching print_operand_value() also convert its "hex" parameter to > bool. And while altering (and moving) oappend_immediate(), fold > oappend_maybe_intel_with_style() into its only remaining caller. Finally > where doing adjustments, use snprintf() in favor of sprintf(). > --- > While doing the conversion I came to notice that print_operand_value()'s > "hex" parameter has only ever passed "true" to it. I wonder why this > parameter still exists. > Andrew, Do you have follow-up patches to pass "false" to print_operand_value? -- H.J.