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

351–360 of 504 posts

Re: Getting Past C

#351

Post by nurettin »

eridius wrote: post #341
nurettin wrote: post #331

Why does 90% of this huge comments section revolve around Rust? Haven't we had enough of the same already? Yes, we know it provides memory safety guarantees. Yes we know you hate everything written in C with great passion. This has been made apparent and banged on our heads for the past several dog-years. Did anyone bother to look at the sheer amount of refactoring the author & team did? Did anyone realize how diffic…

The huge discussion about Rust is because that's literally what this post is about. It's titled "Getting Past C" and most of the post is about considering Go or Rust as the future language for the project. And, not surprisingly, a lot of people think Rust is a great choice for this (and I agree).

The title is Rust-bait so let's all chant rust! Rust! RUST! Oh but there are only three tentative mentions of Rust in it and this entire comment section is corroded. Just compare the two pages in a browser with ctrl-f rust

Re: Getting Past C

#352

Post by PeCaN »

lacampbell wrote: post #288
dbaupp wrote: post #128

Earlier quoted context omitted.

The lack of generics means your array implementation is either going to either: - be implemented with macros and token pasting, and result in a ton of mental overhead because you'll have a pile of types like array_foo for an array of `foo`s, and array_bar for an array of `bar`s, along with a pile of corresponding `foo * array_foo_get(array_foo, size_t)` and `bar * array_bar_get(array_bar, size_t)` functions. - or, ha…

C macros-faking-generics really aren't that bad (your "unsigned char" case is really easy to solve - use another macro). It's a bit goofy having different types floating around like "array_of_int", "array_of_float", but you can create them in a single line when needed, and once you create them, they work, and efficiently. They're not an ideal solution by any stretch, but it's not the nightmare scenario you envision w…

I actually did this¹⋅² some time ago. Since then I've moved on from a hardcore C developer to C++ and Ada³, but it wasn't necessarily a bad solution. I think given how little C gives you to work with, it's the best solution you can do.

It does make debugging a chore. I ended up with a Makefile rule to run the test suite through the preprocessor (and did some hackery to exclude #include of system headers), format it with clang-format, and build that. Not exactly pretty or easy, but it got the job done.

1. https://github.com/alpha123/yu/blob/master/src/yu_splaytree....

2. https://github.com/alpha123/yu/blob/master/test/test_splaytr...

3. Where this sort of thing is much easier and I am happier and more productive.

Re: Getting Past C

#353

Post by PeCaN »

awinter-py wrote: post #247
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…

agree -- inability to do variable-sized arrays on the stack is the root of the problem.

This is what I really like about Ada. Variable-sized arrays and structs on the stack is easy, safe, and efficient in Ada.

Re: Getting Past C

#354

Post by e3b0c »

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, there are actually drawbacks of Rust compared with Go, IMHO. When facing a moderately large project written by others, the ergonomics for diving into the project is not as smooth as Go. There is no good full-source code indexer like cscope/GNU Global/Guru for symbol navigation across multiple dependent projects. Full text searching with grep/ack does not fill the gap well either since many symbols, with their different scopes/paths, are allowed to have the same identifier without explicitly specifying the full path. That makes troubleshooting/tracing a large, unfamiliar codebase quite daunting compared with Go.

Re: Getting Past C

#355

Post by lacampbell »

kbenson wrote: post #330
lacampbell wrote: post #253

Earlier quoted context omitted.

So basically, your argument boils down to "well what if the person who implements the dynamic array doesn't know C properly and provides an API that exposes the internal realloc'd memory?". Because if not, I have no idea what kind of insane dynamic array implementation you have in mind. There is no way you should be able to access pointers to the internal memory from the API of a dynamic array. Here's how it works -…

We seem to be talking past each other. I created a bit of sample code ot show exactly what I'm talking about, it's at https://gist.github.com/kbenson/fbc585d6a6144a2a9f1ef340b913... . The basic idea is that sometimes you might want a pointer to an array item, if that item is complex, not just a copy of it, as there's no need to be wasteful if it's a fairly large struct. Any pointers to that array might be invalidated…

You're right, to an extent we are talking past each other. I totally understand how your code can cause a dangling pointer. But you are using a raw C array, which completely goes against what I've been poorly trying to explain in this thread. What I am advocating is something like this:

https://gist.github.com/anonymous/32df4da4949a6c1067c2be8f20...

so TL;DR, if you don't want to deal with copying structs, malloc them then push them to the dynamic array, and deal with their pointers. Else if you push a struct value on the ray, return struct values.

Re: Getting Past C

#356

Post by wildmusings »

Manishearth wrote: post #333
asveikau wrote: post #322

Earlier quoted context omitted.

OK, so in C you can smash the stack and that's bad. True. But I think you fail to see the larger point I'm attempting to evoke: that array bounds are artificial in the first place, and this doesn't just surface in C. The "heartbleed in rust" example is a great one, and it arises in real life in many high level language APIs for file I/O and sockets. You have an allocation, and you have a count of available bytes comi…

> I wouldn't be surprised if Rust has mechanisms to chop up arrays in the way I describe and enforce the bounds you provide it [T]::split_at is probably what you're looking for. Almost all array handling in Rust is done through slice types which are tagged with sizes.

His point is that you're not forced to do that. And anyhow, that doesn't solve the issue since you can bungle the creation of the slice with the wrong offset or length.

Re: Getting Past C

#357

Post by acjohnson55 »

It's not yet ready for primetime, but Scala Native (http://scala-native.readthedocs.io/en/latest/) might just make a splash in the systems space. I don't think it has anything like ownership yet, but I wouldn't be surprised if it eventually develops that capability. I think you can get it to run without GC, too, but using C Stdlib memory management. Although, that largely defeats the memory-safety.

Just throwing it out there as something to keep an eye on!

Re: Getting Past C

#358

Post by Manishearth »

wildmusings wrote: post #356
Manishearth wrote: post #333

Earlier quoted context omitted.

> I wouldn't be surprised if Rust has mechanisms to chop up arrays in the way I describe and enforce the bounds you provide it [T]::split_at is probably what you're looking for. Almost all array handling in Rust is done through slice types which are tagged with sizes.

His point is that you're not forced to do that. And anyhow, that doesn't solve the issue since you can bungle the creation of the slice with the wrong offset or length.

I wasn't refuting their point. I was just pointing this out.

However, you can't bungle the creation of a slice in rust without using explicitly marked unsafe code.

Re: Getting Past C

#359

Post by steveklabnik »

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,…

RLS will hopefully full that gap.

Re: Getting Past C

#360

Post by wocram »

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,…

I haven't had too many issues with Intellij-rust or racer failing to jump between symbols.

There are also many other tools that provide indexing, eg. ide [plugins], kythe, and the rust language server.

Post reply on HN