---------- Forwarded message ---------
From: Jason McKesson <jmckesson_at_[hidden]>
Date: Sun, Feb 19, 2023 at 12:05 AM
Subject: Re: [std-proposals] set_new_handler extension
To: Phil Bouchard <boost_at_[hidden]>


On Sat, Feb 18, 2023 at 11:39 PM Phil Bouchard <boost_at_[hidden]> wrote:
>
>
>
> On 2/17/23 12:07, Jason McKesson via Std-Proposals wrote:
> > You realize that this proves precisely nothing, right? The source of
> > the bug could still be in your code. Switching memory allocators means
> > switching where the heap tracking stuff is (and a GPU allocator
> > probably puts heap tracking in your CPU's memory rather than GPU
> > memory of which there is far less). So a wild-write which on one
> > allocator hits heap tracking data, would very likely miss heap
> > tracking data on a different allocator. It would hit something else,
> > something that your program is able to tolerate better.
>
> Alright I forgot my laptop is dual-boot with Windows 8.1. So I compiled
> the application attached using clang++ version 8.0 under Windows and
> clang++ version 10.0 under Linux on the *same* laptop of 16 GB of memory.
>
> On Windows, it crashes before printing anything.
>
> On Linux, it works perfectly fine and outputs:
>
> int main(): allocating maximum: 65536 kilobytes.
> void test(int): 1
> void test(int): 2
> void test(int): 4
> void test(int): 8
> void test(int): 16
> void test(int): 32
> void test(int): 64
> void test(int): 128
> int main(): done.
>
> So case closed, I proved my point. The only hope left is to amend the C++ standards.

To amend it to do... what? Fix your *stack overflow*? Because that's
what the Visual Studio debugger told me happened when you stuck a 2MB
array on the stack.

Once I took out your massive stack allocation... it ran fine.

But you are right. The case of Phil Brouchard v Bias against Microsoft
has been closed. You are guilty.