On Monday, 20 February 2023 19:31:16 PST Phil Bouchard wrote:
> > Don't suspect. Prove it.
>
> Prove what? Windows' code is proprietary.

You don't need access to the source to prove the point. You just have to have
a working application that, when run, shows the problem and has no reasonable
other reason for having the behaviour in question than what your hypothesis
is.

> > This is the entire problem with this thread: you're suspecting a problem
> > and jumped to a conclusion that is unwarranted by the facts presented.
> > We've already twice shown that the problem was not where you thought it
> > was, meaning it's very hard to take any argument you're making on trust
> > alone now. You're oh-for-two now; you want a "third time is the charm"
> > case, not "strike three" (mixing my metaphors here).
>
> I just explained it crashes on both Windows 10 and 11 with 28x and 16x
> Intel Core i9 using Visual Studio 2019 in 64 bits Release mode.

And as your later email has just shown, the problem wasn't the allocator; it
was that your application exhausted the address space of a 32-bit application
(which on Windows is 2 GB; on 32-bit Linux it used to be 3 GB and in a 64-bit
Linux kernel, the 32-bit application gets all 4 GB).

You've twice now shown an application that fails to run for a reason that was
not what you thought it was. Your hypothesis remains unproven.

> > Plus, even if your root-causing of the issue had been right, you've not
> > yet
> > demonstrated how your proposed solution would fix anything.
>
> I'm making my point first. I'll write a paper after I made my point.

That's fair, but you haven't made your point yet. And it's not what I meant
here: I wasn't asking for the paper. That indeed comes later. I meant that
your proposal of replacing the allocator is, so far, a solution in search of a
problem, because you haven't shown that a problem exists somewhere in the first
place and that this problem warrants a C++ standard change.

Oh, I know that there are many replacement memory allocators that are good at
different usages compared to the standard one, which is likely optimised for
generic workloads. I also know that there are some that may provide better
resistance against buffer overflows and thereby against remote attacks, under
some circumstances. So yes, there are reasons why one may want to replace
allocators.

The problem of doing this in the standard is that malloc() and friends are
"magic" from the standard's point of view. They obtain memory from somewhere
out of thin air, as far as the standard is concerned. The standard does not
know about mmap() or brk() or VirtualAlloc() or HeapAlloc(). The best you
could do from within the standard is to have one very large static variable
and disburse from it at runtime, which isn't very common on modern operating
systems.

Instead, one is expected to know how the operating system in question
allocates memory dynamically to the application. And since you do know that,
you've stepped outside the standard and may as well use a non-standard
solution to provide your allocator to the application. Therefore, I conclude
that use-cases for replacing the allocator exist, but such situations do not
require a standard change.

> > This is in spite of the fact that you can already do what you're proposing
> > to do, without the need for a modification to the standard.
>
> I saw that it is possible under Linux which is great but that would
> dismiss Windows.

You can replace malloc() on Windows too, but such doesn't propagate to other
DLLs that are already compiled.

> Although low-latency and high-performance algorithms aren't really used
> under Windows, that "operator new and delete overrides across dynamic
> libraries under Linux" knowledge is pretty obscure.

It's not meant to be. It's meant to be an exact reading of the standard: you
may override operator new() and ItJustWorks™. Unlike on Windows, on Linux by
default the multiple shared libraries at runtime behave as if they had been
compiled-time linked together.

That's not the case on Windows, where the DLL import attributes mark a hard
boundary where the C++ standard ends. For example, the following will not
compile on Windows with GCC or Clang, or link if you use MSVC:

extern __declspec(dllimport) int globalvar;
constexpr int *ptr = &globalvar;

because the address of globalvar is not a constant expression due to that
attribute.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering