Hi Phil, this list cannot make decisions. It is only for helping on and consulting/feedback for new proposals. Experiencing that a function works on a Linux system and crashes on Windows is no proof for a certain cause (memory allocation/assignment) of the crashes on Windows. As pointed out by others that can have very indirect causes like hardware instabilities and the Windows code in this case being more demanding in some way. Those difficulties to pinpoint the actual cause of erratic, flighty bugs should be clear for every programmer. So I do not understand, why you write of 'evidence'. Its more like a 'hint'. Others already have pointed out that the Windows memory allocation is one of the most tested and proven components within Windows and >99.9% of the cases, where one (all of us) would honestly think of a bug there, it is actually an unrelated error. If there is a bug, Microsoft would be very eager to fix it. A bug in the memory allocation would typically also be an often easily exploitable security risk. I think everybody on this list has the best intentions for the efficiency and effectiveness of the discussion, so I am sorry if you felt intimidated besides refutal for some ideas and arguments or discouragement for some avenues. Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Phil Bouchard via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 02.04.2023 09:48 Betreff:Re: [std-proposals] Fwd: set_new_handler extension An:std-proposals_at_[hidden]; Thiago Macieira <thiago_at_[hidden]>; marcinjaczewski86_at_[hidden]; CC:Phil Bouchard <boost_at_[hidden]>; On 3/28/23 22:38, Phil Bouchard via Std-Proposals wrote: > > > On 3/27/23 13:01, Thiago Macieira wrote: >> On Monday, 27 March 2023 12:32:45 EDT Phil Bouchard wrote: >>> I could easily figure it out with Clang's memory sanitizer in Linux but >>> under Windows we can't compile CUDA using Clang. >> >> Complain to your CUDA vendor. That has nothing to do with the C++ >> standard: if >> you're using a piece software that you can't modify to your wishes, >> modifying >> the C++ standard is not the solution to the problem. > > I duly noted that the C++ committee is not interested to integrate this > into the standards. > > That doesn't mean I agree given the standards can make use of some major > revamp instead of the never ending minor syntax changes here and there. > > I also proactively think it's pretty obvious that C++ will need to adapt > sooner or later to load balanced algorithms using different types of > parallel processors and memory. > > When I think about it the new virtual table-based memory allocator could > not only be sped up using fast thread-local FIFO memory pages I've > previously shown (3.6x) but also adding the ability to use CPU or GPU > memory pages could also be a great asset. Again, I know the decision is made and I'm not trying to influence the decision but I just wanted to point out I do have evidence now as I'm running the exact same code featuring the readonly function cv::threshold() in multithreaded mode in Linux and it doesn't randomly crash. So I was initially right in my suspicions despite all intimidation. I won't bother Microsoft either because I don't care enough. Thank you, -- Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> CTO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada Banner <https://goglobalawards.org/> 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. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals