From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 269C73895FE5; Tue, 20 Jun 2023 07:50:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 269C73895FE5 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id F191F28AECB; Tue, 20 Jun 2023 09:50:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1687247425; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FYcQpSZ0ZCST0GlImL4XMVz+3niP/kJtTijofu2iEeU=; b=mTsGds4EZLufkQ3m3fYI29G/NyLk14PcJuUfYZzU35D99jFwcsNcyngd5uTvlYx845MIAh aJyXhF4HCPj66H0TyamV92rtpFLjTtVP4v0Jrg710Q/DT3I3BOEv7wx8scu8Oz/z7+SOQi 4oeSb/voQ19WHc1suZPxHQ3LwgSEdNs= Date: Tue, 20 Jun 2023 09:50:25 +0200 From: Jan Hubicka To: Jonathan Wakely Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, libstdc++ Subject: Re: [libstdc++] Improve M_check_len Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > > > > size_type > > _M_check_len(size_type __n, const char* __s) const > > { > > const size_type __size = size(); > > const size_type __max_size = max_size(); > > > > if (__is_same(allocator_type, allocator<_Tp>) > > && __size > __max_size / 2) > > > > This check is wrong for C++17 and older standards, because max_size() > changed value in C++20. > > In C++17 it was PTRDIFF_MAX / sizeof(T) but in C++20 it's SIZE_MAX / > sizeof(T). So on 32-bit targets using C++17, it's possible a std::vector > could use PTRDIFF_MAX/2 bytes, and then the size <= max_size/2 assumption > would not hold. Can we go with this perhaps only for 64bit targets? I am not sure how completely safe this idea is in 32bit world: I guess one can have OS that lets you to allocate half of address space as one allocation. Thanks! Honza