Actually I use Google's TC Malloc under Windows and seems to be a good alternative.

But I was just hoping the ISO standards could be extended down to linker issues.


Thanks anyways,

--
 
Phil Bouchard 
CTO
T: (819) 328-4743
E: phil_at_[hidden] | www.fornux.com
1188 rue Saint-Louis | Gatineau (Qc), J8T 2L8 Canada
Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire.
This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
> On Feb 11, 2023, at 10:59 PM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
> 
> On Saturday, 11 February 2023 19:32:32 PST Phil Bouchard via Std-Proposals 
> wrote:
>> Anyway my point is if Microsoft don't wanna be ISO certified, including low
>> level memory management then it's their choice.
>> 
>> It's the choice also for the industry to disregard non-ISO certified
>> companies.
> 
> Indeed. You can vote with your feet or, more precisely, with your wallet, and 
> choose other options. There are a lot of OSes out there, from tiny, real-time 
> and near real-time ones that are much easier to certify for a purpose (like 
> Zephyr and myNewt and FreeRTOS) to full server and consumer OSes.
> 
> I know a few large companies that don't trust Linux for their server needs or 
> have legal qualms about it, and therefore use FreeBSD. It's their choice.
> 
>>> That's not paranoia. They already did killed Netscapa and Wordperfect
>>> similarly.
> 
> And got in legal trouble for it. Same as when Intel[*] got caught having code 
> that detected competitor processors and chose unoptimised code paths.
> 
> None of this is in-scope for the C++ Standard or this mailing list. There's 
> nothing we can or should do about it. What's more, the Standard is not going 
> to make recommendations that go against the legitimate objections of one of 
> the three main compiler vendors, especially if the objection is "this is not 
> implementable in the OS"..
> 
> [*] disclaimer; I work for Intel, but I have no knowledge of the details of 
> the case at hand.
> -- 
> 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