The issue is that you get opted-into a `__declspec(dllimport)` whenever you
use the standard library. At least some parts are linked via the MSVC C++
Redistributable, IIRC.
The operator new override should affect those parts as well, or the stdlib
implementation is noncompliant.

On Tue, 21 Feb 2023 at 00:05, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>