From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120206 invoked by alias); 2 Oct 2019 18:44:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 120172 invoked by uid 89); 2 Oct 2019 18:44:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-17.9 required=5.0 tests=AWL,BAYES_00,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham version=3.3.1 spammy= X-HELO: mail-ot1-f65.google.com Received: from mail-ot1-f65.google.com (HELO mail-ot1-f65.google.com) (209.85.210.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Oct 2019 18:44:46 +0000 Received: by mail-ot1-f65.google.com with SMTP id e11so84652otl.5 for ; Wed, 02 Oct 2019 11:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VVKv9IcQeG7orMKfPfYEf27UE/7Kqex6zKBM5RItBYc=; b=YhHMJH43IestUERRsub/X/KGR6Gr8FCeHYGoTwstMsEH/pTIBUVbAyxVv6zppU9Fz9 larPXTbsyT0oM+HvwwQTnmO2vpPatFCUZUPKi1DWR8FxZqEP15um2vPGg8FB25W/fmeD I+DyU/oV58uV0ThFyiOnGAMyoCdE7nBP8E7ThlJ92k3XHMTf9GDtCYyNQ9pjS2ruaCKv NX0XyBttvduT4zGzDRNLRWVcjIe8sizZHnDvpgvPGWfRv1fIrNqBaXsg6k/HeTZA17Ws D69Esl6WZi5UO13jWZvSCVl7Dp1mF0gwcw8y95BJeFot6llf46KkSYr8wJHH4fc2YPs+ fL0w== MIME-Version: 1.0 References: <20191001173345.48753-1-cbiesinger@google.com> In-Reply-To: From: "Christian Biesinger via gdb-patches" Reply-To: Christian Biesinger Date: Wed, 02 Oct 2019 18:44:00 -0000 Message-ID: Subject: Re: [PATCH] Change some arguments to gdb::string_view instead of name+len To: Pedro Alves , Tom Tromey Cc: gdb-patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00081.txt.bz2 On Wed, Oct 2, 2019 at 9:45 AM Pedro Alves wrote: > > On 10/1/19 8:29 PM, Christian Biesinger wrote: > > On Tue, Oct 1, 2019 at 2:10 PM Pedro Alves wrote: > > >> I wonder then, I assume that the caller up the stack should know whether > >> the string was originally null terminated? I wonder about tweaking the > >> interface to pass that info down somehow. > > > > Actually, let me come at this from a different direction... > > > > I looked at all the callers. In every case, they either passed a > > nullterminated string or a substring of an existing string. In other > > words, accessing name[length] was always valid, even if the > > string_view wasn't nullterminated. > > > > In light of that, how do you feel about just documenting that callers > > have to pass a string view where accessing [length] is guaranteed not > > to be an invalid memory access? > > My feeling is that one of the points of vocabulary types like string_view is > that you replace documentation with rules or contracts enforced by, or > encoded in the types. To me, it feels like a bit of a hack or design issue that > we switch to string_view while at the same time, find that we need to step > outside its contract. A char * pointer is low level and as such forces > you into a "what exactly am I allowed to pass here?" mind state, while > a string_view has a contract that people should just be able to > assume. > > OTOH, I don't feel that strongly about this case, there are > certainly bigger fish to fry! > > So I guess I'll be happy with just documenting. But > please don't take that as approval. I'd rather defer to Tromey, > since he had started the review, and I haven't even looked at the > whole patch in detail. tromey -- any thoughts on this? As I see it, the two options are: - Always alloca+strcpy (ought to be fairly cheap) - Document that accessing .data()[length] must be valid (or make bfd_demangle take a length, but that doesn't seem realistic) Christian