News for hackers. Stuff that matters.
Re:Getting Past C by panic on Tuesday January 03, 2017 @05:18PM (#13313696)
And it only takes one programmer mistake to bring the whole house of cards down.

Isn't this also true of Rust, with its unsafe keyword? None of these languages are completely safe against programmer mistakes.

Re:Getting Past C by mrsteveman1 on Tuesday January 03, 2017 @05:56PM (#13314038)
> Isn't this also true of Rust, with its unsafe keyword?

> None of these languages are completely safe

No, but the first time I encountered an unexplained segfault in Rust was the first time I've ever found & fixed the cause of a weird segfault message in just a few minutes, because the mistake was in the 12 lines I had written inside a clearly marked unsafe block rather than the other ~3000.

Without something like unsafe blocks, finding known bugs and auditing code for other "weird" memory issues means looking much wider (and often, screaming "what the hell are you talking about?!" at the screen on a routine basis).

Re:Getting Past C by jjnoakes on Tuesday January 03, 2017 @05:52PM (#13313999)
You are equating the unsafe keyword in Rust with entire C codebase.

Yes, carelessness in either could amount to trouble. No, they are not close to the same amount of risk because the relative amount of code in each is orders of magnitude different, and unsafe blocks can be heavily reviewed.

Re:Getting Past C by dbaupp on Tuesday January 03, 2017 @05:55PM (#13314027)
This is true of every language: e.g. Python has ctypes, Haskell has Foreign, Java has JNI, etc. It's a matter of defaults/conventions rather than something being literally impossible to screw up.
Re:Getting Past C by staticassertion on Tuesday January 03, 2017 @05:27PM (#13313773)
Totally. But in the case of rust your vulnerabilities are grep'able. For all of the code you have in a project you only have to search for the unsafe keyword when you want to audit it.

I think that makes a very significant difference.

Re:Getting Past C by jdmichal on Tuesday January 03, 2017 @05:30PM (#13313802)
That's less of a mistake, and more of turning off the footgun's safety. Yes, it still only takes one programmer. But they have to purposefully enable such actions, as opposed to neglect to perform actions through the "proper" abstractions.
Re:Getting Past C by sidlls on Tuesday January 03, 2017 @05:27PM (#13313778)
Yes. It's trivial in Rust to write unsafe code. It's less trivial to mask the unsafe code and the (unproven, in my opinion) argument is that the explicit "unsafe" keyword makes it prohibitively difficult.
Re:Getting Past C by afarrell on Tuesday January 03, 2017 @05:25PM (#13313760)
Is the use of the unsafe keyword a default? I don't know Rust, but from a user interface perspective, it sounds like it has an affordance of "Hey! Pay particular attention to this bit because it is risky!"
Re:Getting Past C by Manishearth on Tuesday January 03, 2017 @06:25PM (#13314258)
It's more of a "Hey, trust me here when I say that the enclosed code is actually safe" hint to the compiler.

It's used sparingly. Not as sparingly as I'd like, but sparingly enough.

Re:Getting Past C by afarrell on Tuesday January 03, 2017 @07:10PM (#13314523)
Sure, but code is not just instructions to a compiler, but is also a user interface.
Re:Getting Past C by Manishearth on Tuesday January 03, 2017 @07:11PM (#13314531)
Oh, yes, as a UI it is "be extremely wary of this code" Often folks write long comments around unsafe code explaining why it is safe. Not always, sadly.
Re:Getting Past C by steveklabnik on Tuesday January 03, 2017 @05:34PM (#13313836)
It is very much not the default.
Re:Getting Past C by EugeneOZ on Tuesday January 03, 2017 @06:17PM (#13314212)
Even without `unsafe` programmer can make mistakes in Rust. Logical mistakes are unstoppable.