Date: Sat, 8 Apr 2023 18:22:58 -0400
On 4/8/23 17:28, Thiago Macieira via Std-Proposals wrote:
>> Well if you read the title of the thread, my initial goal was to clean
>> up this mess with a virtual table-based heap allocator so any client
>> could implement their own implementations for better safety or better
>> low latency algorithms.
>
> So far, I've only heard of a solution in search of a problem to solve. You ned
> to start with the *problem* that needs solving first. In this thread, we've
> heard several times that you thought that Microsoft's heap had a problem, only
> to later be told that the bug was elsewhere. You've alluded to security,
> performance, and latency, but have not yet shown the problem that needs
> solving and discussed the multiple possible solutions for them.
Well we're in 2023 and I still wasted a month trying to pinpoint a
memory problem on Windows. There are ways to solve these problems
implicitly and if anybody claims he never had these problems then he's
living on a different planet.
I still need to fine tune some array initialization in C++ Superset to
adapt to the Clang API but it already handles the security aspect.
Performance and latency are very important factors in the financial
sector as the requests need to be processed in real-time.
And I don't speak for myself here:
https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
Those are the problems I am addressing. Sorry for the lack of introduction.
> Do note that because you've cried wolf three too many times in this thread
> alone, you're going to be greeted with a very skeptical audience.
You may be right on that part but I speak the truth first and foremost
so if I made a mistake myself then I will publicly admit it, not to
mislead anybody. You can count on that.
I'm trying to be proactive at the same time so my conclusions and
advises are to keep developing under Linux first and port it to Windows
after it has been proven to be stable. Not the other way around.
> Finally, this mailing list is NOT the standards committee. We're a group of
> enthusiasts who do offer advice, but we're not official gatekeepers. You can
> disagree with everyone and go straight to a paper for the actual committee.
Ok good.
>> Well if you read the title of the thread, my initial goal was to clean
>> up this mess with a virtual table-based heap allocator so any client
>> could implement their own implementations for better safety or better
>> low latency algorithms.
>
> So far, I've only heard of a solution in search of a problem to solve. You ned
> to start with the *problem* that needs solving first. In this thread, we've
> heard several times that you thought that Microsoft's heap had a problem, only
> to later be told that the bug was elsewhere. You've alluded to security,
> performance, and latency, but have not yet shown the problem that needs
> solving and discussed the multiple possible solutions for them.
Well we're in 2023 and I still wasted a month trying to pinpoint a
memory problem on Windows. There are ways to solve these problems
implicitly and if anybody claims he never had these problems then he's
living on a different planet.
I still need to fine tune some array initialization in C++ Superset to
adapt to the Clang API but it already handles the security aspect.
Performance and latency are very important factors in the financial
sector as the requests need to be processed in real-time.
And I don't speak for myself here:
https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
Those are the problems I am addressing. Sorry for the lack of introduction.
> Do note that because you've cried wolf three too many times in this thread
> alone, you're going to be greeted with a very skeptical audience.
You may be right on that part but I speak the truth first and foremost
so if I made a mistake myself then I will publicly admit it, not to
mislead anybody. You can count on that.
I'm trying to be proactive at the same time so my conclusions and
advises are to keep developing under Linux first and port it to Windows
after it has been proven to be stable. Not the other way around.
> Finally, this mailing list is NOT the standards committee. We're a group of
> enthusiasts who do offer advice, but we're not official gatekeepers. You can
> disagree with everyone and go straight to a paper for the actual committee.
Ok good.
-- 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.
Received on 2023-04-08 22:23:00