On Fri, Jul 18, 2025 at 9:50 PM Jonathan Wakely <jwak...@redhat.com> wrote:
> On Fri, 18 Jul 2025 at 19:18, Tomasz Kaminski <tkami...@redhat.com> wrote: > > > > > > > > On Fri, Jul 18, 2025 at 8:03 PM Jonathan Wakely <jwak...@redhat.com> > wrote: > >> > >> This adds a check when incrementing the shared count and weak count and > >> will trap if it overflows. This also double the effective range of the > >> counts for most 64-bit targets. > >> > >> The counter type, _Atomic_word, is usually a signed 32-bit int (except > >> on Solaris v9 where it is a signed 64-bit long). The return type of > >> std::shared_ptr::use_count() is long. For targets where long is wider > >> than _Atomic_word (most 64-bit targets) we can treat the _Atomic_word > >> reference counts as unsigned and allow them to wrap around from their > >> most positive value to their most negative value without any problems. > > > > I wonder could we return std::numeric_limits<long>::max() from > use_count(), > > if make_unsigned_t<_Atomic_word> value does not fit in the long? > > The value will not increment, but only the usable one is zero. > > True. use_count() has no synchronization, so can be a stale value. So > if we saturate to LONG_MAX we can just say "sorry, the increments > didn't become visible to this thread yet" :-) > This explanation may be challenged, if all increments are sequenced before the check (i.e. they happen on a single thread), so we technically couldn't do that.
