Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Getting Past C

blog.ntpsec.org

Post reply on HN
Print view View original

111–120 of 504 posts

Re: Getting Past C

#111

Post by dbaupp »

rnestler wrote: post #100
lacampbell wrote: post #63

Earlier quoted context omitted.

Would you care to provide a short rust implementation of reading an arbitrary length string from standard input? I have rust installed. I would be curious to benchmark it and see if is indeed faster than the same thing in C, using a user-defined bounds checked array.

Did you mean something like this? use std::io::{self, Read}; fn main() { let stdin = io::stdin(); let mut data = vec![]; stdin.lock().read_to_end(&mut data) .expect("Reading stdin failed"); }

(FWIW, You could golf that to io::stdin().read_to_end(...), because the Read implementation for Stdin does the same locking internally: https://github.com/rust-lang/rust/blob/8f62c2920077eb5cb8132... .)

Re: Getting Past C

#112

Post by jstimpfle »

kazinator wrote: post #70
geofft wrote: post #52

Earlier quoted context omitted.

And once you have written a five line safewrite() function, a hundred-line saferecvfrom() function, a 1500-line safeioctl() function, and all of that, and you have a third-party static analysis tool to prove that you're never calling the unsafe read() or ioctl() functions except from the wrappers, what was the advantage of staying in C in the first place?

The advantage is that you're depending only on yourself and C. That third party static analysis tool can just be "grep". Or some mild text processing on the output of "nm" to validate that no object files (other than the allowed ones) have external refs to those symbols.

Or just disallow platform headers.

Re: Getting Past C

#114

Post by jjnoakes »

panic wrote: post #69
jdmichal wrote: post #66

Earlier quoted context omitted.

Obviously, one can program C to do anything, and write all the provably safe abstractions wished. But, that's not really the point. The point is that doing such is not the default. It requires engagement and knowledge of the programmer, especially on distributed projects with loose communication, such as many open source projects. And it only takes one programmer mistake to bring the whole house of cards down. Why al…

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.

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

#115

Post by loup-vaillant »

mistaken wrote: post #109
staticassertion wrote: post #40

Earlier quoted context omitted.

Because your 'safe' implementation will certainly have a performance cost, and won't be the default. This is why, despite C++ providing std::array, you'll still find buffer overflows in C++ code. C++'s std::array provides the safe 'at' function but you're opting into a performance penalty and it's not the more familiar [] syntax. Rust arrays/ vectors are safe-by-default. To use the unchecked, unsafe version requires…

To be fair the [] syntax is an overridable operator and you could just point it to use the "at" method. Not sure why they've implemented it as an usafe function.

With C++, the default is zero overhead, not safety.

Re: Getting Past C

#116

Post by w8rbt »

I would start by getting the code to compile with g++, then begin migrating the dangerous C constructs to safe C++ constructs. IMO, that would be a safe, reasonable thing to do.

Re: Getting Past C

#117

Post by cwyers »

lacampbell wrote: post #105
pjmlp wrote: post #77

Earlier quoted context omitted.

I have been hearing and reading that from C advocates since 1993. It only got worse.

Not an argument, or even a point. I don't know why this is so difficult for people to understand. Buffer overflows are easy to avoid in C. I think I recognise your name from some rather aggressive rust advocacy in another thread, so I'll try and break this down in a way that won't trigger you: - Buffer overflows are trivial to avoid in Rust, AFAIK. I acknowledge this - Buffer overflows are very easy to code in C, and…

> Do you understand now how it's possible create a safe abstractions in an unsafe language?

Who cares? What's "possible" is completely besides the point. What matters what is done. And so, yes, you can create safe abstractions in C. But if you need to interoperate with someone else's C code, you have to deal with how your abstractions interact with someone else's, or someone else's lack of them. The point of using a language like Rust or Go or... pretty much any non-C language with lots of traction is that you don't have to provide "your own thin abstractions." You use the same one as everyone else. The point of Rust or Go isn't to make things easier on you. It's to protect you from every other piece of code you interact with. The standard library. Libraries written in the language. Other people working on the same project as you. Yourself five weeks ago. You all use the SAME safe abstraction. Nobody has to roll their own. There aren't 25 safe abstractions for 20 people working on the project. You don't have to reason out or guess whether or not some library (or even the standard library) is doing the right thing to avoid buffer overrun. You don't need to defend your entire codebase against someone else's code not doing the right thing.

Re: Getting Past C

#118

Post by pjmlp »

lacampbell wrote: post #105
pjmlp wrote: post #77

Earlier quoted context omitted.

I have been hearing and reading that from C advocates since 1993. It only got worse.

Not an argument, or even a point. I don't know why this is so difficult for people to understand. Buffer overflows are easy to avoid in C. I think I recognise your name from some rather aggressive rust advocacy in another thread, so I'll try and break this down in a way that won't trigger you: - Buffer overflows are trivial to avoid in Rust, AFAIK. I acknowledge this - Buffer overflows are very easy to code in C, and…

I advocate all memory safe systems programming languages, going all the way back to ESPOL on Burroughs B5500, in 1961!

Because I am old enough to remember when C was only relevant to UNIX users and those of us that care about quality code were able to enjoy much better options.

It is not possible, because one seldom works alone, so regardless of whatever laboratory attempts to write safe C code, they all fall down when the team reaches a size of two, or dependencies to binary libraries are required.

C++ is also not free from this. Regardless of the language features we are able to use, there are always a couple of guys that code it like C, thus making an hole under the castle walls.

As for Rust, as any compiler writer knows the implementation language has very little to do with the language being compiled. If LLVM was done in Java, as Chris initially thought of doing, Rust would be using a Java compiler instead.

Re: Getting Past C

#119

Post by steveklabnik »

lacampbell wrote: post #105
pjmlp wrote: post #77

Earlier quoted context omitted.

I have been hearing and reading that from C advocates since 1993. It only got worse.

Not an argument, or even a point. I don't know why this is so difficult for people to understand. Buffer overflows are easy to avoid in C. I think I recognise your name from some rather aggressive rust advocacy in another thread, so I'll try and break this down in a way that won't trigger you: - Buffer overflows are trivial to avoid in Rust, AFAIK. I acknowledge this - Buffer overflows are very easy to code in C, and…

(the Rust compiler is implemented in Rust, though we do call out to LLVM for codegen purposes)

Re: Getting Past C

#120

Post by Peaker »

pklausler wrote: post #25

Honestly, why not do it once and for all in a strongly typed pure functional language, validate it, and then tweak the GC parameters to get the performance? Use the safest and most powerful language that you can, if you can.

GC could possibly expose a program to timing side-channel attacks.
Post reply on HN