From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Y0OS=CI=kam.mff.cuni.cz=hubicka@sourceware.org>
Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16])
	by sourceware.org (Postfix) with ESMTPS id BF04A3858D1E;
	Tue, 20 Jun 2023 08:05:50 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF04A3858D1E
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 DDBAD28AEBD; Tue, 20 Jun 2023 10:05:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1;
	t=1687248349;
	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=8m84U1jz5AYV4349jxvGZcTARvuLDOgnIg59I+T5xGI=;
	b=QSnAgQL5dkV1wzYzVxTt5ARptRzAGxp6QHiGayZRhEfOoMUtM7H+VfzC2cjpfmV15Tfipe
	W2OIZ15IjOmGCUSKP8MfWnaIWu4DdlmqWIsW98QK4Bw7+X7HC04QACwjcE06mIN30JfMym
	4x31RSKdY1dh8XvnKZsassKi3OXaZO0=
Date: Tue, 20 Jun 2023 10:05:49 +0200
From: Jan Hubicka <hubicka@ucw.cz>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>, gcc-patches@gcc.gnu.org,
	libstdc++ <libstdc++@gcc.gnu.org>
Subject: Re: [libstdc++] Improve M_check_len
Message-ID: <ZJFd3T5bDWNfRH3B@kam.mff.cuni.cz>
References: <ZI9MmdQ+OMehcdeg@kam.mff.cuni.cz>
 <CACb0b4kgHajswPwumWtjLeXOMt75tt0jJhmb1-JZ4wzrfXvB4A@mail.gmail.com>
 <ZJA2gJzMkigiwqkZ@kam.mff.cuni.cz>
 <ZJA5/fuVUNpkc3ms@tucnak>
 <CACb0b4nt=mNKYS7+Fwnrf0Kq4umLu0M7Z-SotzCbx7=oEs021g@mail.gmail.com>
 <CACb0b4ksDYihf--ZXr21RS4eDVAAsH4i7wRvYT2BA6XN=ZTznQ@mail.gmail.com>
 <ZJFaQbSqlOuq2hNa@kam.mff.cuni.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZJFaQbSqlOuq2hNa@kam.mff.cuni.cz>
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: <gcc-patches.gcc.gnu.org>

> > >
> > >       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.

Perhaps something like:
  size > std::min ((uint64_t)__max_size, ((uint64_t)1 << 62) / sizeof (_Tp))
is safe for all allocators and 32bit, so we won't need __is_same test
and test for 64bit?

Honza
> 
> Thanks!
> Honza