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

461–470 of 504 posts

Re: Getting Past C

#461

Post by [deleted] »

ue_ wrote: post #419
kqr wrote: post #392

Earlier quoted context omitted.

> I work on a C codebase that does this […]. Yes, there is quite a lot of NIH. With essentially-uniform use of checked data structures, and an extremely comprehensive suite of automated tests getting run under ASAN (originally Valgrind) […]. This is a complex, >1M SLOC distributed system that has seen several years of production use at this point […]. > > […] it just needs to be done from the start, and then you just…

But Rust still won't warn about an out of bounds access (when accessing using a variable) at compile time, and your code will panic at runtime. This isn't the "safety" anyone ought to be expecting from a language billed incessantly as safe. Rust, at least in this regard and probably others too, is no better than C, and for me it isn't enough to justify the horrible and complex syntax.

[deleted]

Re: Getting Past C

#462

Post by leshow »

e3b0c wrote: post #354

Rust has some very desirable properties to me. Writing Rust programs from scratch is not as scary as I've heard of from the internet either. The documentation is excellent, the compiler diagnostic messages are very helpful and the notorious borrow checker didn't stand in my way that much. And I love Cargo and Cargo.io. I have some projects where Rust is the saner choice than Go or other GC based languages. That said,…

crates.io

Re: Getting Past C

#463

Post by leshow »

ue_ wrote: post #419
kqr wrote: post #392

Earlier quoted context omitted.

> I work on a C codebase that does this […]. Yes, there is quite a lot of NIH. With essentially-uniform use of checked data structures, and an extremely comprehensive suite of automated tests getting run under ASAN (originally Valgrind) […]. This is a complex, >1M SLOC distributed system that has seen several years of production use at this point […]. > > […] it just needs to be done from the start, and then you just…

But Rust still won't warn about an out of bounds access (when accessing using a variable) at compile time, and your code will panic at runtime. This isn't the "safety" anyone ought to be expecting from a language billed incessantly as safe. Rust, at least in this regard and probably others too, is no better than C, and for me it isn't enough to justify the horrible and complex syntax.

Do you know what a panic is?

C will actually read arbitrary memory, Rust won't, that's the difference.

We're talking about a situation where the length of the array is not statically known and you access it out of bounds at runtime. Rust checks first if it's out of bounds, and if it is, DOES NOT blindly read the memory anyway (as C would) but exits.

I don't understand how you could think the two situations are at all equivalent.

Re: Getting Past C

#464

Post by jjnoakes »

MaulingMonkey wrote: post #446
jjnoakes wrote: post #445

Earlier quoted context omitted.

What do you expect a language to do if you index an array using a runtime-calculated value? Rust checks at runtime and panics if your program exceeds the bounds. You can opt-in to asking if the bounds are exceeded and fail gracefully if you like, or if you want to promise the compiler you know for sure your bounds are tight, you can use unsafe blocks and act like C. Opt-in to danger. C lets you do it with no checks.…

> What do you expect a language to do if you index an array using a runtime-calculated value? Optimizers already try to prove index bounds to eliminate unnecessary checks, and static analysis tools to demand necessary checks. Turning the latter into compile time errors is a reasonable approach if your language can provide sufficient information to deal with false positives - likely by forcing you to add your own boun…

Sure, but this can be the same in Rust or C, which was the context of this discussion. New languages may provide more tools to eliminate more checks, but in general, if you have a runtime value and you index an array with it, someone has to check somewhere.

And the point of this thread is that Rust's default (check index bounds and fail at runtime unless the check can be proven unnecessary by the compiler or optimizer) is safer than C's default (don't check anything by default and hit UB if the index is out of bounds).

Re: Getting Past C

#465

Post by cesarb »

ue_ wrote: post #421
outworlder wrote: post #187

Earlier quoted context omitted.

I get: thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 4' Looks pretty safe to me.

How is such a crash remotely safe, for example, in an aviation system? Or a hospital's main computer? A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features.

> A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features.

There's one important difference. As far as I know, the bounds checking of gcc or clang can either print a warning and continue, or terminate the process.

A panic in Rust, however, will safely unwind the stack (similar to a C++ exception, in fact it's the same mechanism) and terminate only the thread. The rest of the program can continue running, and even start a new thread to replace the terminated one.

You can see this in action when running "cargo test". A panic in a test (the assert!() and assert_eq!() macros, often used in tests, do a panic in case of failure) will not terminate the whole process; the rest of the tests still run.

Re: Getting Past C

#466

Post by dbaupp »

dreta wrote: post #394
dbaupp wrote: post #161

Earlier quoted context omitted.

So you want the array to have type foo * ? Ignoring that this doesn't let the compiler help the programmer with arrays (you still have to manually remember to use the accessor, not []), you also have to manually remember which pointers are pointers and which are arrays, and this representation doesn't work for pointing into subsections of an array (a similar problem to C-style strings), nor does it work well for putt…

I agree that having to remember is a problem, it's one of the many shortcomings of C that it doesn't let you differentiate between types at compile time. Pointing into subsections works fine. You just have to create a type for it. This solution doesn't have the same problems as strings because you don't rely on a terminating entry, and it's what languages like Rust or Java do as well. You can allocate dynamic arrays…

Creating a type for it, for each type of array, will require exactly the macro array thing I was talking about. And see the sibling comment for how dynamic arrays/alloca isn't relevant, I'm just talking about static arrays. (Dynamic arrays on the stack do have a performance cost, as they get in the way of the compiler's optimiser/code generator: having non-fixed stack frames makes accessing locals annoying.)

Re: Getting Past C

#467

Post by steveklabnik »

ue_ wrote: post #420
steveklabnik wrote: post #136

Earlier quoted context omitted.

Panics are definitely safe. They are significantly different than the segfault you'd get out of the C code.

There are tools you can use with C compilers that don't access OOB memory on OOB access. What's your point? I think I'd rather not have it panic at all. They were making a language from scratch and still didn't solve the crash-at-runtime problem that C has. Instead they just made a common C compiler option default and called it 'safe'. It's worse than the fact that the Go creators ignored years of research after the…

> What's your point?

My point is that panics are memory safe, contrary to what my parent said.

Re: Getting Past C

#468

Post by steveklabnik »

cesarb wrote: post #465
ue_ wrote: post #421

Earlier quoted context omitted.

How is such a crash remotely safe, for example, in an aviation system? Or a hospital's main computer? A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features.

> A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features. There's one important difference. As far as I know, the bounds checking of gcc or clang can either print a warning and continue, or terminate the process. A panic in Rust, however, will safely unwind the stack (similar to a C++ exception, in fact it's the same mechanism) and terminate only th…

(panics are for "non-recoverable" errors, and so don't _have_ to unwind the stack: you can abort on panic as well. The important difference is that you get well-defined behavior in all cases.)

Re: Getting Past C

#469

Post by macintux »

cesarb wrote: post #465
ue_ wrote: post #421

Earlier quoted context omitted.

How is such a crash remotely safe, for example, in an aviation system? Or a hospital's main computer? A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features.

> A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features. There's one important difference. As far as I know, the bounds checking of gcc or clang can either print a warning and continue, or terminate the process. A panic in Rust, however, will safely unwind the stack (similar to a C++ exception, in fact it's the same mechanism) and terminate only th…

This sounds like the "fail fast" philosophy in Erlang. Crashing is the standard behavior for any unexpected data, but the process model makes it straightforward to manage those crashes.

Re: Getting Past C

#470

Post by dbaupp »

ue_ wrote: post #421
outworlder wrote: post #187

Earlier quoted context omitted.

I get: thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 4' Looks pretty safe to me.

How is such a crash remotely safe, for example, in an aviation system? Or a hospital's main computer? A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features.

Something crashing, so an error can be reported and a watchdog can restart it (etc.) is far better than just forging on with corrupt memory and wrong answers.

People do not use the sanitisers nearly as much as they should, and nor are they designed to be used in production. There's has been CVEs issued for them caused by the testing mindset in which they are written.

In any case, how much a programming language helps the programmer get a correct program (I.e. the most general form of safety) is a thing of degree, not all or nothing. Rust does a lot more than C, pushing many many errors to compile time, meaning they're fixed before the code even runs. Sanitisers only catch these when they actually happen, and will presumably result in the runtime crash you're so concerned about, if used in production. The fact that Rust isn't dependently typed and so can't catch OOB at compile time is unfortunate in this respect, but don't throw the baby out with the bath water.

Post reply on HN