From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 672AB3858412; Fri, 15 Oct 2021 05:19:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 672AB3858412 Received: by mail-wr1-x430.google.com with SMTP id r10so24205762wra.12; Thu, 14 Oct 2021 22:19:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=vOG+DnAcbJVapTtR7ncMRZ5H1h0rrflKj9gl6Kbsv+A=; b=NoDiDyYU39rIsNy2NupSR2fZKHKdUEmwW3Yqv1zS6i6MaurwVHD/uNVEf8tU1wiGCS fbpA4yFWrzkfV9/J6+CTzCXylw3sVKbgy+xTja+9EJVlkzrB+n+d+gKh1asSPqvCThoK gX24iToihMu0RtNLiO6CVuMGGqunA567PjFRm5glnLTmMF07P0+A8P4aMwWCMeUuPZVO 7iu+Q1LqJQiRR6msxUdxt/D9l9FhN/pdUlh3XRJp/QUNBxaZuoAKxH+cbxeEwy36V35g ICXyryyoPwfc4E4seR3DaZ7RJ5riA9vGbHyOJyRyn5wmyRMkXgRzth7pr0B5SIdIuUtz L60w== X-Gm-Message-State: AOAM533f6NtaG4k8O8ZiMRByJ1zDUwXwmPxfwAoOsQNH1dk7G4J5GRhR /CBuxWlTCvXwEvm64XpXMxlXqxDYlLSNxQ== X-Google-Smtp-Source: ABdhPJwMXzpzBUyLRf8OAd3AaxOsQcDHfh6xXjPPGfBT1LT1aY6Rjsucgl0NaI7+GiP47Yla3Jxx0g== X-Received: by 2002:adf:f60e:: with SMTP id t14mr3404574wrp.199.1634275157184; Thu, 14 Oct 2021 22:19:17 -0700 (PDT) Received: from ?IPv6:2a01:e0a:1dc:b1c0:99b:249e:40b:5188? ([2a01:e0a:1dc:b1c0:99b:249e:40b:5188]) by smtp.googlemail.com with ESMTPSA id j14sm3725036wrw.12.2021.10.14.22.19.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Oct 2021 22:19:16 -0700 (PDT) Subject: Re: [PATCH] libstdc++: Check [ptr,end) and [ptr,ptr+n) ranges with _GLIBCXX_ASSERTIONS To: Jonathan Wakely Cc: libstdc++ , gcc Patches References: <2f87571d-8f17-6f70-d163-a9a38a2c37db@gmail.com> From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= Message-ID: <2225a991-23e5-ea1e-39d6-f2f007f4fed5@gmail.com> Date: Fri, 15 Oct 2021 07:19:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 05:19:20 -0000 On 14/10/21 7:43 pm, Jonathan Wakely wrote: > On Thu, 14 Oct 2021 at 18:11, François Dumont wrote: >> Hi >> >> On a related subject I am waiting for some feedback on: >> >> https://gcc.gnu.org/pipermail/libstdc++/2021-August/053005.html > I'm concerned that this adds too much overhead for the > _GLIBCXX_ASSERTIONS case. It adds function calls which are not > necessarily inlined, and which perform arithmetic and comparisons on > the arguments. That has a runtime cost which is non-zero. I thought that limiting the checks to __valid_range would be fine for _GLIBCXX_ASSERTIONS. If you do not want any overhead you just don't define it. > > The patches I sent in this thread have zero runtime cost, because they > use the compiler built-in which compiles away to nothing if the sizes > aren't known. I'll try to find out if it can help for the test case on std::copy which I was adding with my proposal. > >> On 11/10/21 6:49 pm, Jonathan Wakely wrote: >>> This enables lightweight checks for the __glibcxx_requires_valid_range >>> and __glibcxx_requires_string_len macros when _GLIBCXX_ASSERTIONS is >>> defined. By using __builtin_object_size we can check whether the end of >>> the range is part of the same object as the start of the range, and >>> detect problems like in PR 89927. >>> >>> libstdc++-v3/ChangeLog: >>> >>> * include/debug/debug.h (__valid_range_p, __valid_range_n): New >>> inline functions using __builtin_object_size to check ranges >>> delimited by pointers. >>> [_GLIBCXX_ASSERTIONS] (__glibcxx_requires_valid_range): Use >>> __valid_range_p. >>> [_GLIBCXX_ASSERTIONS] (__glibcxx_requires_string_len): Use >>> __valid_range_n. >>> >>> >>> The first patch allows us to detect bugs like string("foo", "bar"), >>> like in PR 89927. Debug mode cannot currently detect this. The new >>> check uses the compiler built-in to detect when the two arguments are >>> not part of the same object. This assumes we're optimizing and the >>> compiler knows the values of the pointers. If it doesn't, then the >>> function just returns true and should inline to nothing. >> I see, it does not detect that input pointers are unrelated but as they >> are the computed size is >= __sz. >> >> Isn't it UB to compare unrelated pointers ? > Yes, and my patch doesn't compare any pointers, does it? > +      __UINTPTR_TYPE__ __f = (__UINTPTR_TYPE__)__first; +      __UINTPTR_TYPE__ __l = (__UINTPTR_TYPE__)__last; +      if (const std::size_t __sz = __builtin_object_size(__first, 3)) +    return __f <= __l && (__l - __f) <= __sz; Isn't it a comparison ? But maybe this is what the previous cast is for, I never understood it. Note that those cast could be moved within the if branch, even if I guess that the compiler does it.