duneroadrunner

SaferCPlusPlus-AutoTranslation

C++2017–2020

duneroadrunner / SaferCPlusPlus-AutoTranslation

SaferCPlusPlus-AutoTranslation

This project has been superseded by SaferCPlusPlus-AutoTranslation2 (https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation2) and remains here for posterity.

Explore on GitHub Read Hacker News discussions

3Distinct people

19Mentions

0Explicit recommenders

9GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

This project has been superseded by SaferCPlusPlus-AutoTranslation2 (https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation2) and remains here for posterity.

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 9 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, 1:49:46 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 month19 dated mentions

Observed mentions: 2017-07-01 01:39:57 UTC to 2020-01-25 01:09:20 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
Jul 2017	2017-07-01 00:00:00 UTC	2017-08-01 00:00:00 UTC	2	2
Aug 2017	2017-08-01 00:00:00 UTC	2017-09-01 00:00:00 UTC	1	1
Sep 2017	2017-09-01 00:00:00 UTC	2017-10-01 00:00:00 UTC	1	1
Oct 2017	2017-10-01 00:00:00 UTC	2017-11-01 00:00:00 UTC	1	1
Nov 2017	2017-11-01 00:00:00 UTC	2017-12-01 00:00:00 UTC	1	1
Dec 2017	2017-12-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
Jan 2018	2018-01-01 00:00:00 UTC	2018-02-01 00:00:00 UTC	0	0
Feb 2018	2018-02-01 00:00:00 UTC	2018-03-01 00:00:00 UTC	0	0
Mar 2018	2018-03-01 00:00:00 UTC	2018-04-01 00:00:00 UTC	3	3
Apr 2018	2018-04-01 00:00:00 UTC	2018-05-01 00:00:00 UTC	0	0
May 2018	2018-05-01 00:00:00 UTC	2018-06-01 00:00:00 UTC	0	0
Jun 2018	2018-06-01 00:00:00 UTC	2018-07-01 00:00:00 UTC	1	1
Jul 2018	2018-07-01 00:00:00 UTC	2018-08-01 00:00:00 UTC	1	1
Aug 2018	2018-08-01 00:00:00 UTC	2018-09-01 00:00:00 UTC	0	0
Sep 2018	2018-09-01 00:00:00 UTC	2018-10-01 00:00:00 UTC	0	0
Oct 2018	2018-10-01 00:00:00 UTC	2018-11-01 00:00:00 UTC	1	1
Nov 2018	2018-11-01 00:00:00 UTC	2018-12-01 00:00:00 UTC	1	1
Dec 2018	2018-12-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
Jan 2019	2019-01-01 00:00:00 UTC	2019-02-01 00:00:00 UTC	0	0
Feb 2019	2019-02-01 00:00:00 UTC	2019-03-01 00:00:00 UTC	1	1
Mar 2019	2019-03-01 00:00:00 UTC	2019-04-01 00:00:00 UTC	3	3
Apr 2019	2019-04-01 00:00:00 UTC	2019-05-01 00:00:00 UTC	0	0
May 2019	2019-05-01 00:00:00 UTC	2019-06-01 00:00:00 UTC	0	0
Jun 2019	2019-06-01 00:00:00 UTC	2019-07-01 00:00:00 UTC	0	0
Jul 2019	2019-07-01 00:00:00 UTC	2019-08-01 00:00:00 UTC	0	0
Aug 2019	2019-08-01 00:00:00 UTC	2019-09-01 00:00:00 UTC	0	0
Sep 2019	2019-09-01 00:00:00 UTC	2019-10-01 00:00:00 UTC	0	0
Oct 2019	2019-10-01 00:00:00 UTC	2019-11-01 00:00:00 UTC	1	1
Nov 2019	2019-11-01 00:00:00 UTC	2019-12-01 00:00:00 UTC	0	0
Dec 2019	2019-12-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
Jan 2020	2020-01-01 00:00:00 UTC	2020-02-01 00:00:00 UTC	1	1

What Hacker News says

19 sources

safercplusplus·Jan 25, 2020

Unfortunately, documentation [1] is still kind of lacking. Like Rust (and arguably modern C++ conventions?), the safe subset doesn't support pointer arithmetic directly. You would have to convert the pointer to an iterator (and its target to an appropriate container). Auto-conversion of code that uses pointer arithmetic is challenging, but has been demonstrated to be solvable in the general case [2]. [1] https://github.com/duneroadrunner/SaferCPlusPlus#getting-sta... [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In The C++ Lifetime Profile: How It Plans to Make C++ Code Safer

duneroadrunner·Oct 24, 2019

Last time I looked at it, c2rust translated from C to unsafe Rust, right? I'll point out a (neglected) project[1] to (partially) auto convert from C to a safe subset of C++. For example, if you need a png encoder/decoder library written in C++, perhaps the safest one is here [2]. [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In How to not rewrite it in Rust

duneroadrunner·Mar 19, 2019

Thanks for noticing :) It's been quite a while since I worked on the code, but I believe that the translator intentionally left types declared as "char {star}" unmodified assuming that they were being used as strings [1] rather "regular" array buffers. I'm guessing that dealing with strings would have been a lot more work because it would require providing safe compatible replacements for all the standard C library string functions. I think you should find that array buffers of other types, like "unsigned char" or "const unsigned char", and their associated pointer iterators are translated to their corresponding macros. I'd be interested if you find otherwise. If you're interested, the relevant code for the translator is in the "safercpp" subdirectory [2]. It's not super-well commented so if you have any questions feel free to post them i

Read the rest

n the "issues" section of the repository. [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In Achieving Safety Incrementally with Checked C

Animats·Mar 19, 2019

Saw this in the translated "SaferCPlusPlus" output examples. static void string_set(char** out, const char* in) What happened there? Where are the array types? Wrong place to look? If inference can't make a definitely good decision, maybe translators should guess, conservatively. That is, if it looks like something needs an array type parameter, make it an array type parameter with subscript checking. Then run tests on the translated program and see if that works. That's what humans do on such code. Machine learning has potential here. For any array in a working program, there must be some expression of some variables that expresses the size of the array. If humans can't find that expression, the program is unmaintainable and probably has a bug. There are really 3 cases. 1. this is a pointer, and it's never subscripted or offset. Tha

Read the rest

t's a pointer to a single instance of something. 2. this is a pointer which is subscripted or offset, and we can tell from context how big the array is. 3. This is a pointer which is subscripted or offset, but auto-translation fails to figure out how big the array is supposed to be. The problem is to convert (3) into (2). I tend to think that a good metric for C code quality is how hard that is. If it's not obvious by looking how big something is supposed to be, there's probably a potential bug. [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In Achieving Safety Incrementally with Checked C

duneroadrunner·Mar 19, 2019

> "Unknown" ranges from 49% to 76%. Yeah, this is interesting. They're saying they can't determine whether a pointer targets an array buffer or not? Perhaps they might want to take a look at the (long neglected) "C to SaferCPlusPlus" translator[1] which can do this. (It was an unexpectedly taxing undertaking though.) It converts C arrays and allocated buffers used as arrays into memory safe implementations of std::array<>s and std::vector<>s, so failure to properly identify them would generally result in output code that wouldn't compile. The examples they give of problematic code in the paper: void f(int* a) { *(int**)a = a; } and f1(((int*) 0x8f8000)); don't strike me as the kind you would often encounter in real-world code. > The syntax they use is rather clunky The output code of the "C to SaferCPlusPlus" transla

Read the rest

tor replaces the types and declarations with macros[2] that can be redefined with a compile-time directive to either use the safe C++ implementation, or revert to the original unsafe native C implementation. The argument being that using macros instead of custom syntax makes the source code more versatile. And existing C programmers already "get" macros. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... [2] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...

In Achieving Safety Incrementally with Checked C

duneroadrunner·Feb 12, 2019

Replacing existing unsafe C++ elements with compatible memory safe substitutes[1] might be more expedient. The conversion can even be automated[2] for parts of the code that aren't performance critical. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In Microsoft: 70 percent of all security bugs are memory safety issues

duneroadrunner·Nov 15, 2018

equally shameless: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In There’s a Hole in the Bottom of the C: Effectiveness of Allocation Protection [pdf]

duneroadrunner·Oct 9, 2018

> I want the standards committee to produce a bounds-checked dialect of C where I can choose to pay some perf cost to get real dynamic and bounds-checked arrays If you don't want to wait on the standards committee, the SaferCPlusPlus library provides memory-safe substitutes for commonly used unsafe C/C++ elements (including pointers). These memory-safe elements require a C++ compiler, but because they are largely compatible with their native counterparts, you can write programs that can switch between using memory-safe (C++) elements and (unsafe) straight C elements with a compile-time directive. That is, you don't have to choose between safety and performance when authoring the code. You can make the choice at build-time. So you could, for example, provide both "memory-safe" and "non-memory-safe" builds of your software. There was even a

Read the rest

(now long neglected) tool[1] to automatically replace arrays/buffers in C source code with (optionally) memory-safe substitutes. (Not just bounds-checked, but safe from use-after-free.) > I know I'd trade 10% perf for the elimination of whole classes of security vulnerabilities. Full memory safety may sometimes cost a bit more than that [2]. But a nice thing about this approach is that you can choose to use (faster) unsafe code in critical inner loops, and memory-safe code everywhere else. [1] Shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... [2] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

In The benefits and costs of writing a POSIX kernel in a high-level language

duneroadrunner·Jul 2, 2018

Not sure if it's what you're thinking of, but there is the "C to SaferCPlusPlus" auto-translation helper tool[1]. The idea is that the output can be compiled as straight C, with the safety mechanisms disabled, or with the (compile-time and run-time) safety mechanisms enabled, which requires compilation as C++. The tool is currently being neglected, and at the moment it mostly just translates native arrays, and pointers that are being used as array iterators. I say "just", but actually it addresses what I believe to be (by far) the most difficult issue, which, as other commenters have mentioned, is determining in the general case whether a pointer is actually being used as an array iterator. And it also determines whether that array is a fixed-size array or a (potentially) resizable array. For example, in this code snippet: void foo1(i

Read the rest

nt *p, int n) { foo2(p, n); } does p point into an array, or just at an int? You have to deduce it from context. And there's no theoretical limit to the amount of deduction you might need to do. The tool doesn't automatically translate regular "non-array" pointers yet, but that can be a straightforward task as the SaferCPlusPlus library has a safe, general drop-in replacement for pointers. Translating to "performance optimal" safe pointers is another story. There you have challenges similar to translating to safe Rust I think. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In C2rust vs. Corrode

duneroadrunner·Jun 6, 2018

Don't forget about SaferCPlusPlus[1]. Much safer than conventional modern C++. Also (optionally) uses scope lifetimes to prevent use-after-free. (Not yet fully compiler enforced like Rust, but hopefully that'll be coming at some point.) There is a translation helper tool[2] that, at this point, can automatically replace native C array and pointer iterator declarations with macros that make them memory safe (bounds and use-after-free) when compiled in C++ mode. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus/blob/master... [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In XNU kernel heap overflow due to bad bounds checking in MPTCP

duneroadrunner·Mar 23, 2018

SaferCPlusPlus[1], for example, is a safe subset of C++ that has compatible safe substitutes for C++'s (and therefore C's) unsafe elements. So migrating existing C/C++ code generally just requires replacing variable declarations, not restructuring the code. For C programs, one strategy is to provide a set of macros to be used as replacements for unsafe types in variable declarations. These macros will allow you, with a compile-time directive, to switch between using the original unsafe C elements, or the compatible safe substitutes (which are C++ and require a C++ compiler). The replacement of unsafe C types with the compatible substitute macros can be largely automated, and there is actually a nascent auto-translator[2] in the works. (Well, it's being a bit neglected at the moment :) Custom conventions using macros to improve code qualit

Read the rest

y are not that uncommon in organized C projects. Right? But this one can (optionally, theoretically) deliver complete memory safety. So you might imagine, for example, a linux distribution providing two build versions, where one is a little slower but memory safe. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In C for All

duneroadrunner·Mar 16, 2018

> "guaranteed to be safe" (which will most likely require tooling) rather than merely "safer" - and I will be the first one to promote it myself :-) Well I hope so, as SaferCPlusPlus could use a little promotion :) At this point, despite the name, I think the dialect itself is "safe", not just "safer". Potentially unsafe features are relegated to the "mse::us" namespace and are generally only needed for interop with legacy code. Of course there's no way to enforce that a programmer stick to the "dialect"/subset without some tooling. But I think the "rule" for adhering to the SaferCPlusPlus subset is pretty simple and generally intuitive. That is, "any potentially unsafe element of C++ should be avoided". And I think most of us have a pretty good sense of which C++ elements are potentially unsafe. The (few) unintuitive ones might include t

Read the rest

hings like the implicit "this" pointer (which is a native pointer, so it should be avoided). A tool to enforce adherence would be fairly straightforward to write. When there is sufficient demand it will be provided. At the moment an "auto-translation"[1] tool has higher priority. > quite simple: there are only 3 concepts, with 2 of them ('naked' and 'owning'=unique_ptr<>) being already very familiar It's the same with SaferCPlusPlus, but the 3 "concepts" (pointer types) are "reference counting" pointer (=std::shared_ptr<>), "registered pointer" (= safe, unrestricted naked pointer), and "scope" pointer (basically a naked pointer that is restricted to stack allocation (i.e. a "local variable") and can only point to objects guaranteed to outlive it). The Core Guidelines also has three "concepts"/pointer types (shared, unique, and naked). I suspect that some experience will reveal that SaferCPlusPlus has the better set of pointer types. ... Oh wait, you're the author of the article? In which case, I think it would be worth your time to get more familiar with SaferCPlusPlus. Even if just as research for your own dialect. But with some experience, I think ultimately you might be convinced by the SaferCPlusPlus solution. In fact, there's no reason why your (Re)Actors couldn't be implemented on top of SaferCPlusPlus, which would automatically provide the safe "collections" that you need. Don't hesitate to post any questions in the "issues" section[2]. [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... [2] https://github.com/duneroadrunner/SaferCPlusPlus/issues

In A Usable C++ Dialect That Is Safe Against Memory Corruption

duneroadrunner·Mar 15, 2018

> It's technically possible, but retrofitting old code rarely happens. Yeah. A more realistic solution might be auto-translation of existing code. Here[1] is an example that replaces declarations of arrays, and pointers used as array iterators, with macros that enable the code to be compiled as either unsafe C code or "safe" C++ code (bounds checked and iterator use-after-free safe). Determining in general whether or not a pointer is being used as an array iterator, or a pointer to an array is not trivial. It sometimes has to be deduced from context. Which may be why it doesn't seem to have been done already? [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In Checked C: extension to C that adds static and dynamic checking

duneroadrunner·Nov 10, 2017

> (http://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc-...) It looks like some of those CVEs are dated not that long ago. If code safety is still a concern with this project, you/someone might consider conversion to SaferCPlusPlus (essentially a memory-safe subset of C++). There is an "auto-conversion helper tool"[1] still in development, but already functional. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... (Feel free to post any questions to the github "issues" section.)

In LibHTTP: Open Source HTTP Library in C

duneroadrunner·Oct 6, 2017

> On the other hand, it probably is less effort to rewrite PolarSSL in Rust than doing that proof. It's probably even less effort to convert to SaferCPlusPlus[1] (essentially a memory-safe subset of C++). There's even an tool[2] (under construction, but functional) to do a lot of the conversion for you. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

In Building on Rock, Not Sand

Showing the 15 most recent of 19 sources. Enable JavaScript to search and browse every indexed mention.