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

451–460 of 504 posts

Re: Getting Past C

#451

Post by agumonkey »

steveklabnik wrote: post #361
pjmlp wrote: post #348

Earlier quoted context omitted.

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

This is more than escape analysis, this is removing the GC and associated runtime bits entirely. Escape analysis may not use the GC for those variables, but it is still a pervasive runtime cost in both senses unless it's totally gone.

IIUC there's always some tagging or bit depth loss due to the use of GC ?

Re: Getting Past C

#452

Post by burntsushi »

pekk wrote: post #320
burntsushi wrote: post #284

Earlier quoted context omitted.

That's a great quote, and it's one that Rust---as a a memory safe language---completely embraces. You have the freedom to do anything you want. Some of those things simply require you to type "unsafe."

Forgive me for being cheeky, but just as Rust requires you to type "unsafe," C also requires you to opt in by typing "cc". My serious point is that in practice, the example of C shows that if it is available and people understand that it is "performant" then you will see it all the time, including in libraries you are forced to use.

> Forgive me for being cheeky, but just as Rust requires you to type "unsafe," C also requires you to opt in by typing "cc".

This isn't an accurate analogy at all because I can compile thousands of lines of Rust code without even thinking about needing to use `unsafe`. How many lines of C code can you compile without `cc`?

> My serious point is that in practice, the example of C shows that if it is available and people understand that it is "performant" then you will see it all the time, including in libraries you are forced to use.

Except this is already demonstrably false in the Rust ecosystem.

Re: Getting Past C

#453

Post by giancarlostoro »

eridius wrote: post #335
giancarlostoro wrote: post #183

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.

What do you mean by "they are nowhere near C or C++ where it matters to [you]"? Specifically with Rust (because I already know why Go isn't necessarily a good replacement for C or C++). I know very little about D, one of the few things I know is that it is compatible with C++, which is neat, but that's surely not a concern when talking about C.

As far as being able to write code in a paradigm I'm comfortable in as opposed to being forced into one when the purpose of a language is to replace C++ (which is what Rust and Go both were aimed at). As well as being forced where to put the opening bracket like in Go, which at first didn't bother me, but after a while it became a code smell of itself. There's plenty of talk about Go programmers copying and pasting code, which violates the DRY principle. I like having the option to use GC in D and still being able to compile my code. I even converted some C# code over to D that a project of mine heavily relied on and it compiles perfectly fine regardless of distro or OS I compile it from, granted it was very small / minimal code.

Re: Getting Past C

#454

Post by jjnoakes »

ue_ wrote: post #447
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.…

>You don't automatically segfault if you exceed the bounds; instead you read arbitrary memory. GCC and clang both have sanitizers either built in or available for them. Sure, it's not default, but let's not act like there is no choice in C but to account for every OOB access while programming or to read memory you don't want to. Furthermore, I never said that compile time checks of variables are possible, but rather…

> let's not act like there is no choice in C

If you are using gcc or clang, you have more options. True. But not all C compilers give you those options. However, the point is moot, since I never said you can't catch these things in C; I said it wasn't the default. Which you agree with.

> I never said that compile time checks of variables are possible, but rather we could move to using dependent typing

You didn't say anything about dependent typing. You said "Rust is no better than C". And I'm pointing out that it is. Dependent typing may be even better in some cases; I'm not arguing otherwise.

> Saying you can catch the panic is missing the point of unintentional OOB accesses, which is that they're unintentional.

No one said you should catch the panic. You can use Vec::get() for example if you are using runtime-derived indices and want bounds checking in an ergonomic fashion.

And saying a panic for unintentional OOB is the same as in C is not true, since you get a panic by default in Rust, and to get one in C, not only must you be using a specific compiler or two, you must have the sanitizers enabled for every source file in your program. Not "by default" by any stretch.

> C is just as safe with regard to OOB accessing, and to be honest that's pretty poor in 2017.

It is nowhere close, and saying it is is pretty poor in 2017 as well.

And you are still ignoring pointers, references, lifetimes, threads, ... you know, the other things that also help Rust make "Safe by default" and C "dangerous by default".

Re: Getting Past C

#455

Post by martinhath »

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.

If you are not sure whether the index is in bounds or not, you could use `slice::get`, which returns an `Option`. Sure, it's a little more typing compared to `[i]`, but how would one solve this in any language?

https://doc.rust-lang.org/std/primitive.slice.html#method.ge...

Re: Getting Past C

#456

Post by jdmichal »

userbinator wrote: post #275
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…

Why allow programmers to make mistakes? For a philosophical counterpoint: Why allow anyone to do anything that might possibly be incorrect, harmful, or otherwise perceived by some to be negative? I've looked at a lot of the talk surrounding "safe/secure languages", "safe/secure programming", etc., and yet every time I've heard people preach about the benefits, I feel like I just vehemently disagree. At a very deep an…

Except we're not talking about limiting your freedom of expression. I'd challenge you to give me an example of a program that you can't express in Rust, with the obvious exception of silly and obviously unsafe things like "read from a random memory address". Which, by the way, was deemed so unsafe that the operating system itself will probably kill that program dead. (I can think of one excellent answer off the top of my head that requires `unsafe`.)

We're talking about eliminating a class of programmer error through static analysis. (If you're writing a large C program, you arguably should be using static and runtime analysis tools on it anyway.) This is no different than using a strong type system. Yes, it limits your "freedom", but sending a "banana" to a `sine` function is nonsense anyway. Well, it also ends up that reading 10 bytes into a five byte array is also nonsense, and we now have tools to detect that nonsense and tell you that it is, in fact, nonsense.

Re: Getting Past C

#457

Post by jdmichal »

userbinator wrote: post #408
caconym_ wrote: post #364

Earlier quoted context omitted.

People rely heavily on software in many aspects of their lives. They entrust it with their personal information, their money, and in many cases their physical safety. Engineers building software and companies selling it are ethically obliged to make a good faith effort to prevent defects that might betray their users' trust and cause harm. Languages designed to enhance the safety and security of software written in t…

Are engineering standards for public buildings evil because they stifle architects' freedom to design whatever crazy structures tickle their fancy? The physical analogy is good because even there one can see that there are different standards --- and, unlike what the "safe software" community seems to promote, engineers are not doing the equivalent of making every building strong enough to withstand a nuclear war and…

> ... making every building strong enough to withstand a nuclear war and calling anything less "unsafe".

Yes. Except the equivalent in software is using something like Coq, where your intention is proven to be correct. (You even mention provably correct software in the next paragraph...) And yes, it would be awesome if we could prove every program, because all we would be doing is proving that the programmer's intent is correctly coded into the software, which doesn't limit freedom of expression at all. (I would argue that such is actually an even stronger form of expression, as it's afterwards impossible to misconstrue your intent.)

> Given that there are attempts at even prohibiting Turing-completeness[1][2], I would not be surprised if that eventually happen...

Rust is not one of these, and no one but you seems to have this in mind. So it's a bit of a strawman to be throwing it out here, no? But yes, obviously such a language would limit your freedom of expression.

Re: Getting Past C

#458

Post by [deleted] »

userbinator wrote: post #408
caconym_ wrote: post #364

Earlier quoted context omitted.

People rely heavily on software in many aspects of their lives. They entrust it with their personal information, their money, and in many cases their physical safety. Engineers building software and companies selling it are ethically obliged to make a good faith effort to prevent defects that might betray their users' trust and cause harm. Languages designed to enhance the safety and security of software written in t…

Are engineering standards for public buildings evil because they stifle architects' freedom to design whatever crazy structures tickle their fancy? The physical analogy is good because even there one can see that there are different standards --- and, unlike what the "safe software" community seems to promote, engineers are not doing the equivalent of making every building strong enough to withstand a nuclear war and…

[deleted]

Re: Getting Past C

#459

Post by jdmichal »

ue_ wrote: post #424
jdmichal wrote: post #44

Earlier quoted context omitted.

Why? Rust includes index checks by default, so you have zero chance of programmer error. And, to boot, it removes the checks when the compiler decides that the code is provably safe.

Why does Rust still not warn at compile time and furthermore actually crash (panic) on OOB access if it has the checks you describe?

I never stated whether the checks were static or runtime. In this case, they are runtime checks.

What you are talking about is value range analysis. Rust does a limited amount of it, and if it can prove safe indexing it will remove the runtime checks.

Re: Getting Past C

#460

Post by [deleted] »

ue_ wrote: post #424
jdmichal wrote: post #44

Earlier quoted context omitted.

Why? Rust includes index checks by default, so you have zero chance of programmer error. And, to boot, it removes the checks when the compiler decides that the code is provably safe.

Why does Rust still not warn at compile time and furthermore actually crash (panic) on OOB access if it has the checks you describe?

[deleted]
Post reply on HN