From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf41.google.com (mail-qv1-xf41.google.com [IPv6:2607:f8b0:4864:20::f41]) by sourceware.org (Postfix) with ESMTPS id 442283851C0D for ; Thu, 25 Jun 2020 21:21:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 442283851C0D Received: by mail-qv1-xf41.google.com with SMTP id dm12so3542458qvb.9 for ; Thu, 25 Jun 2020 14:21:00 -0700 (PDT) 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=5JJVUC4oobsJASYGlvPwY1MpGG7H4AAqvUueb0W0KrA=; b=RaZ4qTWxnE9cjnzRdaDlzx1AtZGMthUjs8FLkHB9sfyXrRlkrFn54XPGS4J/q3qai0 CQvjG14tqOkMcbLR1iPyx6x4PhxqBONHq6m+X59LUniZcTPjfUoXmp2NkjCKtIApfy/B 8PxeHg3vy0dH1A4HSfu8xGKgUNZPmXsiJ1a+Wxo9ltosaQPQl1rUR0+wT+CoDIN12exY xra24ZXy+fjUGwICvfOooPQyh445B385kUcEKbI01YngktEBP6TJyTGBAlrEovcM1aMh effg/pk4TQGS7LSvMagyY3aLZ3jZB7ffmtk9ArnqErfCwfBqRj0lazfrzqkgjN4K/6vy BIIQ== X-Gm-Message-State: AOAM531gzLoJwpbyEYrfnf3pJS6Hj+LPLXVumuEFAQmEjFlLdj3U745P 3wv+0j/d6hYgu0bh6PCLX4F9SPAISizU1lsmbSdyCg== X-Google-Smtp-Source: ABdhPJybyK2V+DnKwU0TqrAjSV9QrEsnYbfR2Qzd6b4XKZYCQCUmS3Yiy0AYiPnzOUuuAQK8BNGOxVkcW7crLf8fLrU= X-Received: by 2002:ad4:458a:: with SMTP id x10mr61421qvu.223.1593120058512; Thu, 25 Jun 2020 14:20:58 -0700 (PDT) MIME-Version: 1.0 References: <20200625155517.32173-1-simon.marchi@efficios.com> <5b6a39ca-b29e-262b-1f0c-04fbd21a0c31@palves.net> <7ae6c907-4507-e0c3-3a52-6416a8203987@linaro.org> <04581d9f-2d9b-304c-e223-657f312c4549@palves.net> In-Reply-To: <04581d9f-2d9b-304c-e223-657f312c4549@palves.net> From: Christian Biesinger Date: Thu, 25 Jun 2020 16:20:21 -0500 Message-ID: Subject: Re: [PATCH] gdb: make inferior::terminal a unique ptr To: Pedro Alves Cc: Luis Machado , Simon Marchi , gdb-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.4 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 25 Jun 2020 21:21:01 -0000 On Thu, Jun 25, 2020 at 1:09 PM Pedro Alves wrote: > > On 6/25/20 6:59 PM, Luis Machado wrote: > > On 6/25/20 2:28 PM, Pedro Alves wrote: > >> On 6/25/20 6:18 PM, Christian Biesinger via Gdb-patches wrote: > >>> On Thu, Jun 25, 2020 at 10:55 AM Simon Marchi via Gdb-patches > >>> wrote: > >>>> - current_inferior ()->terminal = xstrdup (terminal_name); > >>>> + current_inferior ()->terminal.reset (xstrdup (terminal_name)); > >>> > >>> Perhaps it really should be a std::string? > >> > >> I think there's no good reason for that. It's a string that doesn't > >> ever need to grow/shrink. And then its use is to pass down to > >> a syscall that accepts C-style null-terminated strings: > > > > I tend to agree with Christian. I suppose one positive outcome is to make the code less cumbersome. It's not like xstrdup is great to read anyway. > > > > Are we worried about performance implications of passing std::string's around like this? > > It's more like -- why store a fat 32 bytes object in the inferior when > a pointer does just as well. There's no code that would benefit from > making this a string, like, there's no strlen call that that would avoid. > The code that wants to consume this wants a pointer. A method-based > interface like I pointed at in that github commit exposes a pointer. > So it would just be implementation detail. Well, if the string is usually short, std::string can avoid a memory allocation... But I guess it comes down to a philosophical question on whether xstrdup/unique_xmalloc_ptr or std::string is more elegant. Christian