On Sun, Feb 12, 2023 at 11:43 AM Phil Bouchard <boost_at_[hidden]> wrote:
>
>
>
> On 2/12/23 11:28, Jason McKesson via Std-Proposals wrote:
> > On Sun, Feb 12, 2023 at 9:55 AM Phil Bouchard via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> >> If you search engine search on Rtl*Heap() functions then this problem
> >> lasted for a long time and all related bug reports were simply
> >> dismissed. I think it's time to turn the page on those issues.
> >
> > That's not how the burden of proof works. You don't get to say that
> > there's a problem with a thing and we need a workaround, and when
> > asked for evidence of that problem then say go find it yourself.
> >
> > I mean you *can* say that, since you just did. But it's not exactly a
> > reasonable response.
> >
> > And for what it's worth, I did spend a few minutes Googling the issue.
> > And the only incidents I found where any actual investigation was done
> > (ie: something more than "a program crashed and the stack trace named
> > this function") all resolved down to application-caused heap
> > corruption. Which... is not a problem even your suggestion could
> > actually fix.
>
> My goal here is to find solutions to problems; not to find problems to
> solutions.

If you want a solution to be accepted by others, it needs to not have
problems. I always thought that went without saying.

> Memory allocations are a huge cybersecurity problem (70%) and needs to
> be fixed at all layers, starting with core allocations routines. That's
> an undeniable fact.

This is the first time you've mentioned "cybersecurity" as a
justification. So which is it? Do you want this because
"RtlAllocateHeap() and RtlFreeHeap() aren't reliable in extensive
multithreading usages?" Or do you want it for "cybersecurity" reasons?

Also, is `RtlAllocateHeap`, or memory allocation functions in general,
a point of attack for hackers? Sure, memory allocation is a security
issue, but my understanding is that this usually manifests in how the
allocated memory gets *used* (buffer overruns and the like), not the
allocation functions themselves. But maybe I'm wrong; if it's such an
"undeniable fact", then it should be pretty easy to cite some
examples.

And it would also be useful to explain how being able to swap the
allocator would fix those examples.

If you want people to buy into your solutions, you first need to
explain what specific problems your solution intends to solve. And
when someone questions a problem you cite, jumping to a different
problem makes it seem like you're just trying to find some
justification for a solution you've already decided is good.