Why does 90% of this huge comments section revolve around Rust? Haven't we had enough of the same already? Yes, we know it provides memory safety guarantees. Yes we know you hate everything written in C with great passion. This has been made apparent and banged on our heads for the past several dog-years. Did anyone bother to look at the sheer amount of refactoring the author & team did? Did anyone realize how difficult this is and what they might learn from this tarrasquesque ordeal they went through? Oh no, apparently it is C and logic mandates that Rust supercedes it so why.the.hell.bother.
Getting Past C
331–340 of 504 posts
Re: Getting Past C
#332Earlier quoted context omitted.
My point is, a lot of people are spending time on this when it doesn't matter. In the limit that AI starts replacing human developers these subtle differences in language approaches zero. New languages here and there every day. Replace this replace that. When, in the end everyone is simply reinventing the "wheel" over-and-over. All these languages end up as assembly.
This sounds a lot like "why clean up my room when the heat death of the universe is coming anyway?", but if you do think that AI is going to supplant all of programming then be the change you want to see in the world! Get building and we'll see which one happens first. I honestly don't know who I'd put my money on between "AI takes over the world" and "programmers stop writing buffer overflows"
My guess is that if they make a general purpose programming AI then all other jobs will also be nonexistent besides being famous and doing YouTube reviews of movies. My thought is that the problems in the way of AI programming are more difficult and can be generalised to enough other jobs that programming is going to be the last job automated.
Re: Getting Past C
#333Earlier quoted context omitted.
That's a different "problem", not to mention a flaw in the application code's design rather than an example of one of the language's building blocks being fundamentally able to allow the entire execution path to be subverted.
OK, so in C you can smash the stack and that's bad. True. But I think you fail to see the larger point I'm attempting to evoke: that array bounds are artificial in the first place, and this doesn't just surface in C. The "heartbleed in rust" example is a great one, and it arises in real life in many high level language APIs for file I/O and sockets. You have an allocation, and you have a count of available bytes comi…
> I wouldn't be surprised if Rust has mechanisms to chop up arrays in the way I describe and enforce the bounds you provide it
[T]::split_at is probably what you're looking for.
Almost all array handling in Rust is done through slice types which are tagged with sizes.
Re: Getting Past C
#334Earlier quoted context omitted.
> Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? The CVE database. Just because you 'can' write such an array implementation doesn't mean you will, doesn't mean your third party libs will, doesn't mean any of your legacy code uses it, and certainly doesn't mean…
> I ask this in bad faith: I encourage you to share a single nontrivial codebase which actually creates the abstraction you've described and religiously adheres to using it throughout. As to why this is in bad faith: I'm definining "nontrivial" here to mean using 3rd party APIs - which will operate on C style arrays, not your project specific safe wrappers - and thus by definition won't be "religiously" sticking to s…
Would you care to point to or write a blog about the principles of this strategy? It sounds immensely useful to the many C developers out there as a potential set of best practices to adopt.
Re: Getting Past C
#335I wish more mention of D would happen. It is compatible with C and C++ libraries and features GC without sacrificing the good things of C and C++. I always loved the idea of Rust and Go but they are nowhere near C or C++ where it matters to me. D fits the bill, otherwise I just use Python. I like being able to design software in my own way as opposed to being told how to do it.
What do you mean by "they are nowhere near C or C++ where it matters to [you]"? Specifically with Rust (because I already know why Go isn't necessarily a good replacement for C or C++). I know very little about D, one of the few things I know is that it is compatible with C++, which is neat, but that's surely not a concern when talking about C.
Re: Getting Past C
#336Earlier quoted context omitted.
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 straightforward than these C to Rust/Go translators. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...
I thought you have an interesting solution to improving safety of C++ code. So, your techniques work with C code done in the old and new C styles w/ no work? Just fire and forget translation of C code written in arbitrary styles to to be completely memory-safe?
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 you consider them separate things), right? SaferCPlusPlus provides safe compatible replacements for pointers (and new/malloc and delete/free). There is a "general" safe pointer type that can be used as a direct substitute for native pointers in most situations, but can sometimes have a noticeable performance cost, depending on usage. Faster safe pointers are also provided, but cannot be used in all situations.
Replacing all the pointers and arrays in your C code with the safer substitutes will eliminate the possibility of invalid memory access, in your code. Of course this doesn't prevent them from occurring in any unsafe libraries you use, including the standard library.
Also, there are certain behaviors in C that may not translate well to SaferCPlusPlus. Like exotic pointer arithmetic. Or, for example, you could imagine some C code that compares two pointers that point to items that have already been deallocated to see if they were previously pointing to the same item. Is that valid in C? Anyway, that kind of thing is not supported by the safe pointers.
There is not yet an automatic translator from C to SaferCPlusPlus, but the translation for most code is straightforward and direct. No new paradigms or "Rust borrow checker" type restrictions. You can check out the benchmark code I linked to in my comment to see examples of C++ code before and after conversion to SaferCPlusPlus. A little code reorganization sometimes helps to achieve optimal performance. But isn't that always the case? :) And of course, SaferCPlusPlus requires a modern C++ compiler and has dependencies on the standard library.
Re: Getting Past C
#337Why does 90% of this huge comments section revolve around Rust? Haven't we had enough of the same already? Yes, we know it provides memory safety guarantees. Yes we know you hate everything written in C with great passion. This has been made apparent and banged on our heads for the past several dog-years. Did anyone bother to look at the sheer amount of refactoring the author & team did? Did anyone realize how diffic…
[deleted]
Re: Getting Past C
#338Earlier quoted context omitted.
> there's nothing stopping the compiler from optimizing the GC out. I don't know of a single language that comes with a GC that does this, do you? > He was comparing against what you'd get if you dropped down to ye olde C or Assembly and wrote the same algorithm there, without redundant work or waste. Right. I agree with this. But basically, we are arguing over an extremely fine semantic, which is "should you even wa…
I'm not arguing about whether bounds checks are good , but about whether it's correct to call them zero-cost in the canonical sense. Doing so just devalues the term, and IMO feels like misdirection. To put it another way, let's say I was a C++ developer on the fence about Rust. If I read this conversation, I'd see that indexing gets called "zero-cost" despite the overhead. Since tons of things in Rust are "zero-cost"…
I think you have a good point. It makes more sense to think and talk about as Rust's implementation of bounds checked indexing syntax as being a zero cost abstraction for writing `if` statements everywhere. I.e. Assuming you want bounds checking, you can't do better than what Rust does despite having nice syntax etc.
Re: Getting Past C
#339Earlier quoted context omitted.
You pretty much just can't; that's what Manish was referencing above about this kind of thing being awkward. It would be cool to have those things, but it also means that there's less "magic" stuff going on, which is nice. And it makes the semantics of stuff like this a lot simpler. > Does `drop()` get called on objects that have been copied from? Nope. In fact, Copy types can't have a Drop at all, but types that mov…
Thanks for all the responses, I'm learning a lot. This explains to me why iterators and other references to the internals of a data type have to take ownership of the whole data type, which is something I ran into several times during my (brief) explorations with Rust.
> have to take ownership of the whole data type,
This isn't the case. They only need to borrow it. A borrowed value isn't allowed to move (the borrow itself can be copied around and shared within the scope of the borrow), so that works out.
Most Rust iterators only borrow the container or iterator they operate on. It's only explicitly moving iterators like .into_iter() (which extracts elements by-move) that don't.
Re: Getting Past C
#340Earlier quoted context omitted.
One thing that I've heard might be a difference, but haven't confirmed yet: Rust's lack of move constructors. So you have a vector, it's full, you push one more. It has to reallocate. How do you copy all of the elements over to the new allocation? In Rust, it's a straight memcpy of T * n bytes. But due to move constructors in C++, IIRC they must be moved one at a time. Again, I haven't actually dug into this; maybe s…
How would a self-referential object work in Rust in that case? The move or copy constructor could not be a simple memcpy. The self-reference would point to the old object. See this for an example: http://ideone.com/sEFtbN
https://github.com/Kimundi/owning-ref-rs exists, but basically you just don't do intrusive datastructures on the stack in rust.
(Intrusive datastructures on the heap are doable with some tricks.)
They're not very essential so it works out.