On Wed, Jul 17, 2024 at 8:20 AM M.C.A. (Marco) Devillers via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> > Message: 1
> > Date: Wed, 17 Jul 2024 01:12:18 +0200
> > From: Bjorn Reese <breese_at_[hidden]>
> > To: "M.C.A. (Marco) Devillers via Std-Proposals"
> > <std-proposals_at_[hidden]>
> > Subject: Re: [std-proposals] Save Cascading Free of Smart Pointers
> > Message-ID: <56272db2-6dfa-679f-0dd8-3609be7d3877_at_[hidden]>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> >
> > On 7/16/24 23:13, M.C.A. (Marco) Devillers via Std-Proposals wrote:
> >
> > > Because C++ smart pointers are based on RAII it is easy to trigger an
> > > overflow of the C stack since destructors call each other. Smart
> > > pointers are supposed to be safe, smart pointers are likely to be used
> > > extensively in the future, and this behaviour could make a large
> > > number of C++ programs core dump unexpectedly.
> > > This proposal is to remove this behaviour from GCCs standard library
> > > and also showcases a small trick by which that can be done.
> >
> > So the problem is that your data structure (list_node) keeps a linked
> > list of smart pointers, and the destructor invokes the destructor of the
> > nested data structure, which invokes the destructor of... etc. causing
> > a stack overflow.
>
> No, my problem in general is that smart pointers cause segfaults
> through cascading frees.
>
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 16 Jul 2024 19:36:46 -0400
> > From: Jason McKesson <jmckesson_at_[hidden]>
> > To: std-proposals_at_[hidden]
> > Subject: Re: [std-proposals] Save Cascading Free of Smart Pointers
> > Message-ID:
> > <CANLtd3WShsGE5Sy77oEQvCmzJuZKMmQ_WZJP0MApwyyZh1L2Xw_at_[hidden]>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > On Tue, Jul 16, 2024 at 5:14?PM M.C.A. (Marco) Devillers via
> > Std-Proposals <std-proposals_at_[hidden]> wrote:
> > >
> > > I came up against this and wanted to float an idea. It doesn't seem
> > > popular but I think I am right. This should be resolved.
> > >
> > > Document number: xxx
> > > Date: 2024-7-16
> > > Audience: GCC email list
> > > Reply-to: marco.devillers_at_[hidden], std-proposals_at_[hidden]
> > >
> > > I.
> > > II. Introduction
> > >
> > > Because C++ smart pointers are based on RAII it is easy to trigger an
> > > overflow of the C stack since destructors call each other. Smart
> > > pointers are supposed to be safe, smart pointers are likely to be used
> > > extensively in the future, and this behaviour could make a large
> > > number of C++ programs core dump unexpectedly.
> > > This proposal is to remove this behaviour from GCCs standard library
> > > and also showcases a small trick by which that can be done.
> >
> > This small trick does not "fix" the "problem".
> >
> > Your `safe_unique_ptr` works, but if someone writes a `list_node` type
> > that manages the memory directly through its destructor (instead of
> > relegating it to `unique_ptr`), then that type has the same problem.
> > The problem exists for every RAII type and would have to be solved
> > *independently* for every RAII type.
>
> My problem is with smart pointers, not what other people do.

Proposals for the standard should actually fix the problem that they
purport to, not merely the tiny subsection of it that bothers one
individual.

> > It also doesn't seem to work across different types. Like, if
> > `list_node` held a `unique_ptr<T>` whose `T` holds a `shared_ptr<U>`,
> > this cascade doesn't work.
>
> I.e., one would need a solution for smart pointers in general. I agree
> with that.
>
>
> > ------------------------------
> >
> > Message: 3
> > Date: Tue, 16 Jul 2024 16:45:24 -0700
> > From: Thiago Macieira <thiago_at_[hidden]>
> > To: std-proposals_at_[hidden]
> > Subject: Re: [std-proposals] Save Cascading Free of Smart Pointers
> > Message-ID: <2705644.vuYhMxLoTh_at_[hidden]>
> > Content-Type: text/plain; charset="utf-8"
> >
> > On Tuesday 16 July 2024 14:13:20 GMT-7 M.C.A. (Marco) Devillers via Std-
> > Proposals wrote:
> > > This cascading free behaviour was noticed during the development of
> > > the Egel language interpreter, and the author has great interest in
> > > having this resolved. The problem was discussed on various channels
> > > and together with Alipha on libera.net a solution was developed. The
> > > idea was subsequently floated on the GCC mailing list where it was
> > > forwarded.
> >
> > In addition to what others have said, this allocates memory during the
> > destruction phase, so your safe_unique_ptr destructor is noexcept(false).
> > That's a big design problem: we try to have them be free of exceptions.
> > Because what happens if you run out of memory while trying to free memory?
> >
> > What happens if you're trying to free memory *because* you're about to run out
> > of memory? Instead of freeing memory, you'd end up causing the very thing
> > you're trying to prevent.
>
> Yes, we are now in the domain of how cascading frees of reference
> counted objects are normally handled, by allocating space in the
> header of the objects such that a stack can be created in-situ without
> allocation.
>
> I find that a bit overkill but at some point in time I expect we'll
> arrive there.

Or maybe users can just... not cascade smart pointers in silly ways.