On Sat, 12 Oct 2024 at 14:13, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Oct 11, 2024 at 6:45 PM Chris Ryan wrote:
>
> > > Why not deallocate it in main in the end in that case?
> >> I honestly think that you should always free your resources.
> >
> > This is a C++ discussion list.
> > That code looks like it is asking/talking about C.
>
>
> I'm taking a wild guess here that you consider code to be C if it
> calls 'malloc'.
>
> 'malloc' hasn't been made deprecated in the C++ Standard, so using it
> in a C++ program doesn't make your program a C program.
>
> The function, std::deliberate_leak, could have two forms, one which
> pairs with 'new' and one which pairs with 'malloc'.
>
> Instead of having a standalone function, "std::deliberate_leak", we
> could alternatively have:
>
> char *p = new(std::leak) char[64u];
>
> char *p = static_cast<char*>( malloc_leak(64u) );
>
>
Using it with new would also mean the objects are not going to be destroyed
either, that's potentially more than just a memory leak.


> When it comes to closing a program very quickly, the big three
> operating systems close all files and free all heap memory
> automatically, so if there's nothing else to do and I want to
> annihilate the program, then I just use three assembler instructions:
>
> mov $60, %rax
> mov $0, %rdi
> syscall
>


_Exit() seems preferable for that purpose.