On 4/2/23 04:58, Sebastian Wittmeier via Std-Proposals wrote:
> 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.

On Windows it appears to be some random memory corruption despite the
fact that readonly OpenCV functions are all thread safe and there is no
reason they shouldn't be as OpenCV is stack based like all other
software. So by all logic one thread's stack shouldn't interfere with
another thread's stack.

I already made the effort to bring this up to this level but again I
won't report this to Microsoft as I do not have the time.

> 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.

Ok thank you. I just want to clarify that I'm not some beginner here as:
- I am part of the SCC ISO/IEC JTC 1/SC 22;
- I have 23 years of experience for companies in California, Ontario and
Quebec;
- I am the founder of an innovative startup;
- I enjoy astrophysics as well:
https://www.fornux.com/files/pdf/Finite_Theory.pdf

So people shouldn't take for granted what I say has no basis. Thanks.

> 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
>
>

-- 
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.