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

181–190 of 504 posts

Re: Getting Past C

#181

Post by Manishearth »

lossolo wrote: post #159
Manishearth wrote: post #154

Earlier quoted context omitted.

> doesn't matter which language you use Idris.

Care to elaborate? I don't see how this can be done without trading space/time over solution without bound checking.

It won't work in all cases :) IIRC Idris will move type info to runtime if it can't prove it at compile time.

Basically, in Idris I can have a function concat which takes a Vector, a Vector, and produces a Vector. You can have arbitrary expressions there, and even things like a function which returns a different type based on its boolean argument.

So most signatures will just carry dependencies through, but some things are dependent on runtime input and that's when the "N" part of the type will be tracked at runtime. At least, that's how I think it works.

Dependent types help eliminate large swaths of bounds checks. Not all of them, and I'm not sure how much better it does than a good optimizing compiler.

Re: Getting Past C

#182

Post by lossolo »

Manishearth wrote: post #158
lossolo wrote: post #36

Earlier quoted context omitted.

I think he means to work with raw memory so using unsafe keyword and in this case he is right. And you can't implement certain things in Rust if you are on the quest for maximum efficiency without using unsafe.

This is throwing the baby out with the bathwater though. You need unsafe to do some things in Rust, sure. But usually this code is isolated and auditable, and nowhere near the linecount of the rest of the application. Even the operating systems written in Rust have pretty conservative use of unsafe (redox, Phil's OS, etc). Most of your code won't be working with raw memory operations, most of it will work with zero-c…

> You need unsafe to do some things in Rust, sure.

And that's what I wrote.

> Most of your code won't be working with raw memory operations, most of it will work with zero-cost abstractions on top of raw memory.

For some web applications sure but industry is not constrained only to writing web applications especially if you want to get into C market space. In HPC or time/space constraint environments this matter.

Re: Getting Past C

#183

Post by giancarlostoro »

I 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.

Re: Getting Past C

#184

Post by jjnoakes »

dhsjxhx wrote: post #113

Rather than looking for a new language, why not ban programs from writing to executable memory?

That is done already in many cases.

Note that doing that doesn't fix all of the problems that out of bounds array writes can cause though.

Re: Getting Past C

#185

Post by Manishearth »

lossolo wrote: post #182
Manishearth wrote: post #158

Earlier quoted context omitted.

This is throwing the baby out with the bathwater though. You need unsafe to do some things in Rust, sure. But usually this code is isolated and auditable, and nowhere near the linecount of the rest of the application. Even the operating systems written in Rust have pretty conservative use of unsafe (redox, Phil's OS, etc). Most of your code won't be working with raw memory operations, most of it will work with zero-c…

> You need unsafe to do some things in Rust, sure. And that's what I wrote. > Most of your code won't be working with raw memory operations, most of it will work with zero-cost abstractions on top of raw memory. For some web applications sure but industry is not constrained only to writing web applications especially if you want to get into C market space. In HPC or time/space constraint environments this matter.

I'm not talking about web applications. I'm talking about systems programming. Even the operating systems written in Rust use unsafe pretty conservatively. Servo uses unsafe mostly to talk to native libraries. Rust is used more for lower level programming than it is for webapps as far as I can tell.

You might want to define further what you mean by "raw memory here". Rust lets you work with arrays and vectors and the heap safely just fine. These are designed as zero-cost abstractions over raw memory (slices, Vec, Box). The equivalent C (with relevant bounds checks) wouldn't be any faster. Rust does not let you do things like call out directly to malloc/free safely. But that's okay. The existence of these abstractions means that you rarely have to do this.

> And that's what I wrote.

.... huh? that's exactly why I put "sure" there, that means I agree with that statement, what followed was why I disagree with the conclusions.

Re: Getting Past C

#186

Post by derefr »

steveklabnik wrote: post #176
derefr wrote: post #170

Earlier quoted context omitted.

If you're relying on any random third-party Rust crates you haven't audited yourself, don't you lose the safety guarantee? A given crate might turn out to have implemented operations on some data-structure using unsafe blocks, and then to have failed to mark its own API functions as unsafe in turn (like the Rust stdlib does, but without the "extensive manual auditing" that the stdlib gets). AFAIK, cargo doesn't have…

That's why I said "safe code," I mean, not using any unsafe. The issue you're talking about is related, but different.

Right, I was just trying to put a finer point on your use of "using any unsafe" here. It sounds like you mean "using" in the lexical sense (writing the token "unsafe" in your code), but you mean it in the dynamic sense (having an unsafe block in your control flow graph.)

Re: Getting Past C

#187

Post by outworlder »

EugeneOZ wrote: post #131
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…

No, Rust arrays are not safe by default: https://is.gd/iY5lPQ

I get: thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 4'

Looks pretty safe to me.

Re: Getting Past C

#188

Post by afarrell »

Manishearth wrote: post #152
afarrell wrote: post #78

Earlier quoted context omitted.

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!"

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.

Sure, but code is not just instructions to a compiler, but is also a user interface.

Re: Getting Past C

#189

Post by civility »

Ericson2314 wrote: post #75
civility wrote: post #53

Earlier quoted context omitted.

We were talking about reading into a bounds checked array. Rust does not user iterators for this.

I cannot trust people to correctly iterate in order through an array in C, and thus must resort to bounds checking them.

This still has nothing to do with what I've said. Take care.

Re: Getting Past C

#190

Post by Manishearth »

afarrell wrote: post #188
Manishearth wrote: post #152

Earlier quoted context omitted.

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.

Sure, but code is not just instructions to a compiler, but is also a user interface.

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.
Post reply on HN