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

341–350 of 504 posts

Re: Getting Past C

#341

Post by eridius »

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

Re: Getting Past C

#342

Post by alexkehayias »

staticassertion wrote: post #104
sidlls wrote: post #76

Earlier quoted context omitted.

How do you suppose runtime bounds checks are done in Rust? They certainly also incur a performance penalty in not-trivial cases. Also, "safe by grep audit" means "safe according to a human." The argument of course is that it lowers the surface area of what a human must be trusted to verify. I'm still not convinced by that argument, because human error is a thing. And for actual systems programming, "very rare" may no…

> How do you suppose runtime bounds checks are done in Rust? They certainly also incur a performance penalty in not-trivial cases. Certainly. I didn't intend to imply otherwise. > Also, "safe by grep audit" means "safe according to a human." Again, totally correct here. > The argument of course is that it lowers the surface area of what a human must be trusted to verify. I'm still not convinced by that argument, beca…

I wrote a little tool to help check Rust crates on GitHub. It's been really interesting seeing how different libs use unsafety. https://github.com/alexkehayias/harbor

Re: Getting Past C

#343

Post by [deleted] »

steveklabnik wrote: post #316
LukeShu wrote: post #314

Earlier quoted context omitted.

as far as I can tell you can't really create a C compatible shared library from [Go]. Sure you can! (as of Go 1.5, iirc) Change your build command to use the c-shared build mode: go build -buildmode=c-shared Then, to change the linkage of the functions you want to export, use the magical comment "//export" directive: //export MyFunction func MyFunction(arg1, arg2 int, arg3 string) int64 { ...

This still doesn't get over the inherent overhead in calling between the two languages though, right? (And you're bringing that whole runtime with you. Which might be okay! As always, it depends.)

[deleted]

Re: Getting Past C

#344

Post by awinter-py »

Ericson2314 wrote: post #252
awinter-py wrote: post #245

> One such cleanup: we’ve made a strong start on banishing unions and type punning from the code. These are not going to translate into any language with the correctness properties we want. Really? This sounds like idiomatic rust to me (heavy with enums).

C unions have no discriminant. But yeah it's a pity—I'd try to hack up discriminated unions then. Or convert to Rust unions and then enums and remove unsafety.

C union declarations should correspond pretty closely to rust enum declarations.

It's a surprisingly important feature. Every large codebase I've worked on has clunky workarounds for storing heterogeneous types in collections.

Haven't seen a silver bullet; dynamic languages are great at this until you have to scale (either in lines of code, number of types or dataset size) and then they become unmanageable. Static languages force you to type a lot and build in-memory ETL-style transformations but scale better. Using SQL is another solution, but that separates you from the language's type-checker and can be another source of error.

Type safety at the serialization boundary was the promise of CORBA and protobuf but we need better tools. I hope we see more focus on ser/des types in the next generation of industry languages.

Re: Getting Past C

#345

Post by flukus »

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…

Because if (a big if) we ever move beyond C then rust is looking to be the biggest contender.

Re: Getting Past C

#346

Post by pjmlp »

scott_karana wrote: post #249
MaulingMonkey wrote: post #171

Earlier quoted context omitted.

> Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? The CVE database. Just because you 'can' write such an array implementation doesn't mean you will, doesn't mean your third party libs will, doesn't mean any of your legacy code uses it, and certainly doesn't mean…

Hate to tell you, but JavaScript implementations virtually all rely on C or C++ as well. And it's not limited to the VM itself: check out npm "native extensions" like `json`. Not to mention glibc, or the OSes themselves. By your definition, nothing is safe. And you're right ;)

Historical accident, given that the better alternatives, for various reasons lost their market share to C and C++, while Sun and Microsoft had the dumb idea of not supporting the same AOT compilation to native code on their new languages from day one.

Re: Getting Past C

#347

Post by anthk »

>Under Linux, some SECCOMP initialization and capability dances having to do with dropping root and closing off privilege-escalation attacks as soon as possible after startup.

Thanks, Eric. Now, FFS, learn how the Cathedral model WORKS, get OpenBSD, learn pledge(2) and stop spreading old FUD against C.

Re: Getting Past C

#348

Post by pjmlp »

steveklabnik wrote: post #286
Veedrac wrote: post #285

Earlier quoted context omitted.

If you never allocate, there's nothing stopping the compiler from optimizing the GC out. Then you get your first property back, in the sense you originally gave. My point is that Bjarne Stroustrup wasn't comparing against writing the exact same program the exact same way. He was comparing against what you'd get if you dropped down to ye olde C or Assembly and wrote the same algorithm there, without redundant work or…

> there's nothing stopping the compiler from optimizing the GC out. I don't know of a single language that comes with a GC that does this, do you? > He was comparing against what you'd get if you dropped down to ye olde C or Assembly and wrote the same algorithm there, without redundant work or waste. Right. I agree with this. But basically, we are arguing over an extremely fine semantic, which is "should you even wa…

> I don't know of a single language that comes with a GC that does this, do you?

Java, .NET, Go, ML and Lisp compilers.

Escape analysis allows to do that, even if just in certain special cases.

Plus the more one uses value types and less heap, the GC needs to work less, specially if we take languages like Modula-3 into this mix.

Re: Getting Past C

#349

Post by steveklabnik »

awinter-py wrote: post #344
Ericson2314 wrote: post #252

Earlier quoted context omitted.

C unions have no discriminant. But yeah it's a pity—I'd try to hack up discriminated unions then. Or convert to Rust unions and then enums and remove unsafety.

C union declarations should correspond pretty closely to rust enum declarations. It's a surprisingly important feature. Every large codebase I've worked on has clunky workarounds for storing heterogeneous types in collections. Haven't seen a silver bullet; dynamic languages are great at this until you have to scale (either in lines of code, number of types or dataset size) and then they become unmanageable. Static la…

Close, but not quite: unless the type is NonZero, you need space for the tag.

c-style unions are in nightly behind a flag; they're not stable yet.

Re: Getting Past C

#350

Post by simondedalus »

lacampbell wrote: post #56
Animats wrote: post #42

Earlier quoted context omitted.

The track record of two decades of CERT advisories for buffer overflows suggests that doesn't work in practice.

Just because people fail to do something doesn't mean it's not both possible and easy.

obviously decades of security advisories means it's not easy. what in the world does 'easy' mean in your current usage? surely "tons of failures" is a better indicator of difficulty than "it feels easy to me / that's 'naturally how my brain works'," etc.

and of course, if lots of people fail at something, it will get proportionally harder with a larger team / larger codebase / different stakeholders demanding xyz, etc etc etc.

not chiming in about the basic disagreements in this thread, but the repeated claim that something that has caused trouble for countless professionals is "easy" just can't be right. if all the qualified people are "unqualified" because they all fail at something "everyone can do," the speaker is the one who's confused, and it's a lexical problem.

Post reply on HN