From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 526223857705 for ; Tue, 20 Jun 2023 08:08:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 526223857705 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687248488; h=from:from:reply-to: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=FNhZ4YFsaytR/v62aF1GjeDproNuQB05zYbK/BLUbUU=; b=Vz0Hw6gONUmJq+0mmc/9s2zOg/kmQTlSl2V0Jor3czWLXLmWTST2M4mDiMgQ9PB/U1vzZH cFolf645nAIJ7EA3C0f9kZjlTgJlmBDzyRu7fRGMr2gWs2Wrw6OiXUHhGvg528DfGLyo5k JeXGlTR+CN1TbJ7k8MzqQIGhdur0iaU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-7-VdXFmWePM3urQhaD8rh8Mg-1; Tue, 20 Jun 2023 04:08:05 -0400 X-MC-Unique: VdXFmWePM3urQhaD8rh8Mg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 42E02101A529; Tue, 20 Jun 2023 08:08:05 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 025272166B26; Tue, 20 Jun 2023 08:08:04 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 35K87xJ11712188 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 20 Jun 2023 10:07:59 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 35K87wK71712187; Tue, 20 Jun 2023 10:07:58 +0200 Date: Tue, 20 Jun 2023 10:07:58 +0200 From: Jakub Jelinek To: Jan Hubicka Cc: Jonathan Wakely , gcc-patches@gcc.gnu.org, libstdc++ Subject: Re: [libstdc++] Improve M_check_len Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Jun 20, 2023 at 09:50:25AM +0200, Jan Hubicka wrote: > > > > > > 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. Is it safe even on 64bit targets? I mean, doesn't say PowerPC already allow full 64-bit virtual address space? The assumption that one can't have more than half of virtual address space allocations is true right now at least on x86-64, aarch64 and others, but isn't that something that can change with newer versions of CPUs without the need to recompile applications (add another level or two of page tables)? By being hardcoded in libstdc++ headers those assumptions will be hardcoded in lots of applications. Jakub