From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 237753857C6A; Thu, 14 Oct 2021 17:11:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 237753857C6A Received: by mail-ed1-x531.google.com with SMTP id w19so26911466edd.2; Thu, 14 Oct 2021 10:11:02 -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:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=9ChmC3BXETaAVBHfYAJpDuVR7W0tYRMXVc0g8agsfoM=; b=R7zm+iorqlyqf81iDX07iw1+hU9KuSwnOXWKMu/4VzZFuQ/h6KSBzEiZxvfXaLcDXw Eghd0ha8z0oN+83K88+6ip3Gu1h1lj+dTuRazH3283IQw73WBm4/Ad/mJCRnCLCbxvWO BJw/vmzm4pUJYzBP0U8TBD9f/mmyDUVB7WSQgwb/LdEZ5JxF2lZi0ySUTothT7Fg+BOU T2zNJQViOhaWpQmG6AUDV02tD5Ee9MuJYIppdASV5ApKv8gXGLmAGQeQ0NScL5GWNUad 0jhtwy5QkKc6PdYmp4qUeUxq0MdiuiTpTxDHWNSxl/m8UGiLpNarjpP+zVhIMsx7mKd7 VWgQ== X-Gm-Message-State: AOAM533mtPFaceKywLXH6CtXjeu1SRrX04aR0HezPj9xB2+J2owPOc52 vbDewYgKUx/9UkVbtKSB4Fqr1dh3hWY= X-Google-Smtp-Source: ABdhPJyLk2N0lpZ924i9zwU4khHSHuwTKCJKG9ZlGl1vEV15S+QpnSsBmWAaIq70Uchkf0B0dW3kRQ== X-Received: by 2002:a17:906:a894:: with SMTP id ha20mr131419ejb.505.1634231460339; Thu, 14 Oct 2021 10:11:00 -0700 (PDT) Received: from [10.40.4.108] ([109.190.253.15]) by smtp.googlemail.com with ESMTPSA id d3sm2426432ejb.35.2021.10.14.10.10.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Oct 2021 10:10:59 -0700 (PDT) Subject: Re: [PATCH] libstdc++: Check [ptr,end) and [ptr,ptr+n) ranges with _GLIBCXX_ASSERTIONS To: Jonathan Wakely , libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org References: From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= Message-ID: <2f87571d-8f17-6f70-d163-a9a38a2c37db@gmail.com> Date: Thu, 14 Oct 2021 19:10:55 +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=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 17:11:08 -0000 Hi     On a related subject I am waiting for some feedback on: https://gcc.gnu.org/pipermail/libstdc++/2021-August/053005.html 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 ? > I would like to also enable that for Debug Mode, otherwise we have > checks that work for _GLIBCXX_ASSERTIONS but not for _GLIBCXX_DEBUG. I > tried to make that work with the second patch attached to this mail, > but it doesn't abort for the example in PR 89927. I think puttingthe > checks inside the "real" debug checking functions is too many levels > of inlining and the compiler "forgets" the pointer values. > > I think the first patch is worth committing. It should add no overhead > for optimized builds, and diagnoses some bugs that we do not diagnose > today. I'm less sure about the second, since it doesn't actually help. > Maybe the second one should wait for Siddhesh's > __builtin_dynamic_object_size to land on trunk. > > Taking this idea further, we could do something similar for > __glibcxx_requires_string, which is currently almost useless (it only > checks if the pointer is null) but could be changed to use > __valid_range_n(_String, char_traits<...>::length(_String)) > so that we can diagnose non-null terminated strings (because the > length that char-traits would give us would be larger than the size > that __builtin_object_size would give us). > > Thoughts? > >