duneroadrunner

SaferCPlusPlus-BenchmarksGame

C++2016–2020

duneroadrunner / SaferCPlusPlus-BenchmarksGame

SaferCPlusPlus-BenchmarksGame

Some benchmarks for SaferCPlusPlus

Testing & Quality

Explore on GitHub Read Hacker News discussions

2Distinct people

12Mentions

0Explicit recommenders

5GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Some benchmarks for SaferCPlusPlus

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

duneroadrunner/safercplusplus · linked in 7 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2016-12-20 02:01:28 UTC to 2020-01-24 19:09:40 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	2	2
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	3	3
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	1
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	5	5
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	1

What Hacker News says

5 sources

safercplusplus·Apr 16, 2019

> like a weak pointer that work with unique_ptr, but I do not think it is possible to do this while preserving zero overhead implementation I think the type of pointer you're asking for basically does exist. First, you want to distinguish the cases when you want a "full featured" weak pointer that can gracefully handle the destruction of its target object [1] (rarely the case), or you just want a non-owning pointer that detects when the prorammer screws up and lets the target object be destroyed prematurely [2]. The latter is essentially just a non-owning reference counting pointer. The optimizer should be able to discard matching increments and decrements of the reference counter in many cases. > This will have overhead, but it could be worth it for the security gains. The performance cost of avoiding "unsafe" C++ elements is measurable,

Read the rest

but reasonably modest [3]. [1] https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [3] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

In Virtually Unlimited Memory: Escaping the Chrome Sandbox

duneroadrunner·Mar 19, 2019

> What guarantees that the "while" loop will not run away and take "data" outside the array bounds? What do you mean "the array bounds"? The code is memory safe. "data" is an iterator that knows exactly what array/container it's pointing to, and that container knows its own size. Dereferences are bounds checked (by default). This translated code is not intended to be performance optimal. The translator does not add, remove or rearrange any of the original source code elements, it simply replaces some of them with macros that are defined as functionally equivalent, memory safe C++ substitutes for the original element. Doing it this way has the benefit of allowing you to "disable" the memory safety mechanisms by reverting the macro definitions to the original (unsafe) elements. I have not yet gotten around to addressing performance of the t

Read the rest

ranslated code. In order to preserve the ability to revert back to pure C code, there would need to be an additional set of macros (like maybe an "array view" macro) that could be mapped to their (safe) high performance C++ counterparts but that would be more restricted in their usage. But at this point I think the value of that is questionable. If you need your code to be memory safe and high performance, the most expedient thing to do is to just accept the translated code as C++ code (or SaferCPlusPlus code) and re-optimize the performance bottlenecks as idiomatic SaferCPlusPlus code. SaferCPlusPlus is, along with Rust, the fastest [1] option for memory (and data race) safe programming. And if you don't like the C++ language as whole, just (define and) stick to a subset you're comfortable with, right? I mean, (I think your proposal is fine as an extension of C, but) I don't see the point in extending the C language with things like views/slices/spans, when the C language is already extended with those. It's called C++ (or some subset thereof) right? And with C++ you can solve the memory (and data race) issues much more comprehensively and performantly (if that's a word :) than with any extension to C. No? [1] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

In Achieving Safety Incrementally with Checked C

duneroadrunner·Mar 7, 2019

They are working on it. The analogue to the borrow checker in C++ is called the "lifetime profile checker" and (an incomplete version) is included in MS Visual C++, but last time I checked (in January) it seemed to still have too many false positives to be practical. In the mean time, I think "the minimum necessary changes" to achieve memory and data race safety is to replace all your unsafe C++ elements (pointers, arrays, vectors, string_views, etc.) with compatible substitutes from the SaferCPlusPlus library [1]. You don't even need to replace them all at once. You can replace them incrementally and your code will continue to compile and run throughout the process. And where needed, maintain maximal performance as well [2]. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCP

Read the rest

lusPlus-BenchmarksG...

In Serious Chrome zero-day

duneroadrunner·Mar 7, 2019

I suggest that the most expedient (cheapest) language to migrate the existing code base to would be a memory safe subset of C++ [1]. In practice most of the safety benefit could be obtained from a just a partial migration. Specifically, just banning raw pointers/views/spans and non-bounds-checked arrays and vectors. From a quick glance at the code in the (quite small) patch diff, the code in question includes: DOMArrayBuffer* result = DOMArrayBuffer::Create(raw_data_->ToArrayBuffer()); ... raw_data_.reset(); ... return result; I'd imagine the effort/time/money it would take to replace those raw pointers with memory safe substitutes [2][3][4] (and enforce the ban going forward) would be relatively modest. Performance shouldn't be an issue [5]. [1] shameless plug: https://github.com/duneroadrunner

Read the rest

/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [3] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [4] https://github.com/duneroadrunner/SaferCPlusPlus#scope-point... [5] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

In Serious Chrome zero-day

duneroadrunner·Jan 10, 2019

Well if you're starting a project now that you expect to live for many years, there's the issue of C++ safety now, and C++ safety in the foreseeable future. Right now projects have the option of building with the santizers (particularly the address sanitizer) enabled, right? The executable would be slower and less memory efficient, but it would eliminate most of the critical CVEs that exploit invalid memory access. Is there a reason Google couldn't provide alternative builds of Chrome with the santizers enabled? As for the foreseeable future, you can come up with arguments (convincing or otherwise) that C++ will be effectively memory (and data race) safe in the foreseeable future. At some point, presumably the core guidelines lifetime checker will enforce memory safety. To what degree it will in practice is a matter of speculation, but in

Read the rest

theory it could be as effective as the Rust compiler. Just as an observation, if you peruse the chromium source code, from a modern C++ perspective, there seems to me to be an alarming prevalence of raw pointers. (Probably understandable as chromium's been around for a while.) C++ is now a very powerful language, and if (memory) safety is a priority it is already practical (and performant[1]) to avoid the use of notoriously unsafe elements like raw pointers and unchecked buffers in favor of safer alternatives. (It is similarly practical to avoid data race prone elements[2].) [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG... [2] https://github.com/duneroadrunner/SaferCPlusPlus#multithread...

In The State of Software Security in 2019