5 ms·
It's a miracle! We have the solution to every bug in every program that will ever be written! Just do not put bugs in your code, you fools! ...
by giosch 9y ago
It's a miracle! We have the solution to every bug in every program that will ever be written!
Just do not put bugs in your code, you fools!
...
- DiabloD3 9y agoTechnically, that's why Rust was invented.
- illumen 9y agoDiablo's law. As an online technical discussion grows longer, the probability of a mention for rewriting in Rust approaches 1.
- simion314 9y agoBu Rust also must have an allocator under the hood that is unsafe and rust apps can call C libraries or C kernel so why do I see the Rust strike team complaining that something that they use indirectly is improved.
- pjmlp 9y agoThere is a big difference in using a programing language where unsafe code is explicit and easy to track down, versus one where each line of code is a possible security exploit. Also Rust isn't the only option to write more secure code, it was already possible before C was even created using Algol and PL/I variants. Quote from Tony Hoare's ACM award article in 1981, regarding Algol use in the industry, a programming language almost 10 years older than C. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." EDIT: younger => older
- simion314 9y agoYes, there are many languages that are safer, including c++ collection can be used safely but you don't see Java/c# devs popping up in a C/C++ related thread mentioning again their favorite language. Btw there are also languages that are safer then Rust and you do not see those people asking to not use Rust, again better tool for the job(where in most of the cases the project is a huge one and is done).
- pjmlp 9y agoHow young are you? I imagine you missed the BBS and USENET flamewars against C.
- simion314 9y agoI have internet access for 10 years.
- pjmlp 9y agoWhich means you missed all that BBS and USENET bashing fun. No, bashing C is a common practice from those of us on the memory safe side of the fence since the early days. Take the paper "A History of CLU"[0] describing how CLU was designed and implemented in 1975. "I believe this is a better approach than providing a generally unsafe language like C, or a language with unsafe features, like Mesa [Mitchell, 1978], since it discourages programmers from using the unsafe features casually." There are tons of other examples, all available in old papers, BBS and USENET archives. [0] http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-561.pdf http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-56...
- simion314 9y agoThanks, I will read it, so are you of the opinion that there is no job that C is the best tool? Btw I am not a C developer and I would never use C except if I am asked to work on a project that uses C already. I would use C++ with Qt for GUI though.
- jlg23 9y agoRust uses jemalloc.
- kdbg 9y agoRust uses a different allocator actually, jemalloc which doesnt store data inline like ptmalloc does. So an overflow could overwrite other heap stored data it wouldn't overwrite heap metadata or result in a vulnerability from the allocator code. Granted, if you link/call in code that uses ptmalloc (glibc's malloc) in Rust it is still an issue but unsafe code in Rust itself won't be vulnerable to this sort of attack.
- rurban 9y agoNo. Technically that's why "safe" languages were invented. Rust is one of the worse examples of those, as you can hardly call Rust safe. Only Rust fanboys do so. Pascal, ADA, LISP, ATS, Java, Go, D, pony and all of the lisp and functional languages are safe.
- steveklabnik 9y ago> as you can hardly call Rust safe Care to expand on that? I'm curious.
- rurban 9y agounsafe memory and unsafe concurrency. i will not expand further, because it will be downvoted by the rust fanboys.
- steveklabnik 9y agoOkay. If you find something isn't safe, in safe code, please file a bug. What you're asserting shouldn't be true.
- rurban 9y agoDo you see the problem now? You have a whole chapter about unsafe, with 4 major cases. Stdlib is full of unsafe. And you don't even talk about unsafe threaded code. One of the biggest safety problems nowadays. Memory safety is solved since decades with GC. Concurrency safety also for a few years.
- kibwen 9y agoEven aside from preemptively complaining about downvotes, refusing to substantiate your claims is the quickest way to lose karma. :P
- Noughmad 9y agoNo, but we do have a solution to one kind of bugs, which is buffer overflows. Just because it doesn't solve every bug doesn't mean it doesn't help.
- faragon 9y agoIt is not about being "smart", it is about reducing the risk. E.g. you can avoid using malloc() directly, using abstractions, even in C, e.g. [1]. [1] https://github.com/faragon/libsrt https://github.com/faragon/libsrt