duneroadrunner

13 ms·

91.
by duneroadrunner 10y ago
Actually, the Ragel generated code (fragment) looks like it's already pretty SaferCPlusPlus compliant, since it itself doesn't declare any buffers or pointer/iterators. So I guess the recommendation instead would be for Cloud
92.
by duneroadrunner 10y ago
It's a good point, but at least with Go the leak would be limited to the allocated buffer. This is probably a case where Rust or C++ might be more helpful. Presumably you wouldn't want to allocate a new (variable sized) buffer eac
93.
by duneroadrunner 10y ago
And if you need a more expedient fix for existing C/C++ code, there's SaferCPlusPlus[1]. [1] https://github.com/duneroadrunner/SaferCPlusPlus
94.
by duneroadrunner 10y ago
I'm not familiar with Ragel, but you might consider adding support for SaferCPlusPlus[1] as an output target. It should be a fairly simple modification of your existing C or C++ output generator. SaferCPlusPlus was, in part, designed f
95.
by duneroadrunner 10y ago
std::shared_ptr works, but fyi often there's a slightly better alternative. For cases where the target object is not shared between asynchronous threads, mse::TRefCountingPointer[1] is smaller/safer/faster/more scalable.
96.
by duneroadrunner 10y ago
Yeah, that's my point. Even though, unlike C++, (safe) Rust was designed to be (memory) safe from the start, it's notable that Rust and C++ end up (or will soon end up) in the same place - a "usable" safe language and an
97.
by duneroadrunner 10y ago
> Issues with C++ safety aren't just a matter of a dangling pointer that should've been a unique_ptr or shared_ptr. It's massively naive to think that this would in any way be comparable to Rust. While I agree, I would po
98.
by duneroadrunner 10y ago
> It transliterates C into unsafe Rust. That's not too helpful. From the author's perspective it is helpful. If the goal is to make an existing C project memory safe without sacrificing performance and memory efficiency, one wa
99.
by duneroadrunner 10y ago
> it looks to be some sensible guidelines/practices But more notably I think, a whole bunch of custom functions and data types to be used in place of more typical C coding practices. The document references a number of (presumably
100.
by duneroadrunner 10y ago
Yeah, the idea is that C/C++ has a finite set of "dangerous" elements. SaferCPlusPlus attempts to provide safe compatible substitutes for those elements. In C, basically the only dangerous elements are pointers and arrays (if
101.
by duneroadrunner 10y ago
As we've discussed, one issue is the big performance cost of these solutions. Anyone interested in working on an automatic C to SaferCPlusPlus[1] translator? It should address the performance issue[2]. And should be much more straightf
102.
by duneroadrunner 10y ago
So do you agree that Rust should remain a "high transparency" language? Do you have an opinion on a "high productivity"/"application level safety supporting" superset of the language? Rust seems to be cree
103.
by duneroadrunner 10y ago
Hmm. Is it less transparent than vectors which use implicit run-time bounds-checks? Don't RefCells use implicit run-time checks? (Btw I don't know Rust very well, so feel free to correct me.) And what about the question mark opera
104.
by duneroadrunner 10y ago
Yeah, I'm a bit worried that Rust is raising the floor, but maybe lowering/hardening the ceiling when it comes to code safety. I mean, if you consider static (compile-time) versus dynamic (run-time) safety, Rust leans heavily towa
105.
by duneroadrunner 10y ago
Rust may ultimately be the better solution for many or most cases, but right now SaferCPlusPlus[1] may be the more expedient solution for existing C/C++ code bases. > Any time your code takes in untrusted input, it should not be wri
106.
by duneroadrunner 10y ago
You know, while C++ references are technically unsafe, there is TRegisteredRefWrapper<> [1]. It's a safe version of std::reference_wrapper. Which kind of acts like a reference. So, if you don't mind me using std::strings ins
107.
by duneroadrunner 10y ago
> returning a proxy object from operator[] instead of a reference. Oh yeah, maybe. But that would still require the ability to overload the dot operator, wouldn't it? And how would you know when to deallocate the proxy object? And p
108.
by duneroadrunner 10y ago
Native C++ references are technically unsafe, so code that uses them would not qualify as "strict" SaferCPlusPlus code. In the case of your example, the "double&" is technically not kosher. The easiest way to make it
109.
by duneroadrunner 10y ago
> the compiler won't let me get it wrong. It's far far far too easy to screw up multithreaded code if you're using any kind of shared data, and Rust is the only language I know of that truly makes it safe without compromis
110.
by duneroadrunner 10y ago
> and so I'm stuck with C++ If you're stuck with C++, might as well do it safely: (shameless plug) https://github.com/duneroadrunner/SaferCPlusPlus
111.
by duneroadrunner 10y ago
Well, I don't know about java's reputation, but there's this: http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend... http://www.cvedetails.com/product/1526/SUN-JRE
112.
by duneroadrunner 10y ago
While you're checking out the performance of Rust and Go benchmark implementations, you can also check out some SaferCPlusPlus benchmarks[1] (and kind of compare them with other languages (transitively via the C++ benchmaks)). I'v
113.
by duneroadrunner 10y ago
Yes, after reading a draft[1] of this document, I suggested to them that they seemed to be insufficiently emphasizing remote execution vulnerabilities (due to invalid memory access). I also pointed out that they neglected to mention Rust an
114.
by duneroadrunner 10y ago
While this is a great site for comparing "maximum language speed potential", I think in 2016 it would also be of interest to compare the performance of memory safe implementations as well. This would be particularly relevant for l
115.
by duneroadrunner 10y ago
Yup. SaferCPlusPlus has vector and array substitutes that will also catch "use-after-free" bugs and use of invalid iterators. Clang/LLVM and gcc also provide "sanitizers" with much more comprehensive checking. But t
116.
by duneroadrunner 10y ago
Well, since they seem to be including collections of elements, each with dependency on one or two files, SaferCPlusPlus[1] could be added to the "data structures" category. It's a collection of safe compatible substitutes for
117.
by duneroadrunner 10y ago
You mean, that if there isn't some kind of (automated) enforcement, programmers will continue to "taint" code with unsafe elements? Yes, but just like one might anticipate the development of a good IDE/tool/libray&#
118.
by duneroadrunner 10y ago
But that argument doesn't necessarily call for a new language, it only calls for the prohibition of the unsafe elements of the existing language. Intuitively one might assume that potentially unsafe elements (like pointers, references,
119.
by duneroadrunner 10y ago
While conventional C++ is a vast improvement in memory safety, it does not, at the moment, fully address the problem. Complete memory safety may be achieved if/when the "Core Guidelines Lifetime Checker"[1] is completed, but
120.
by duneroadrunner 10y ago
Not yet, unfortunately. It might be a while before I get a chance to address it, so if anyone out there is looking for a project, it should be fairly straightforward. At least compared to tools like the subject of this post that engage in s

More ›