Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Safety Profiles Failed

circle-lang.org

Post reply on HN
Print view View original

131–140 of 233 posts

Re: Why Safety Profiles Failed

#131

Post by bluGill »

bjornsing wrote: post #93
mimd wrote: post #90

I'm confused over lines such as "Profiles have to reject pointer arithmetic, because there’s no static analysis protection against indexing past the end of the allocation." Can't frama-c/etc do that? Additionally, section 2.3 is narrower than what is implied by the words "safe" and "out-of-contract" and is more concerned with what C/C++ call "undefined behavior" requirements than contract correctness. Ie. An integer…

How is it supposed to do that (in the general case)? If I write a C++ program that will index out of bounds iif the Riemann hypothesis is true, then frama-c would have to win the millennium prize to do its job. I bet it can’t.

Often when I look into questions like this I discover the general case is impossible, but simple hysterics can get 99.999% of the cases and so I can get almost all the benefit even though some rare cases are missed.

Re: Why Safety Profiles Failed

#132

Post by gpderetta »

lmm wrote: post #118
gpderetta wrote: post #99

Earlier quoted context omitted.

> The idea that sustained bugfixing could occur on a project that was not undergoing active development is purely wishful thinking yet the idea that a project no longer actively developed will be rewritten in rust is not?

> yet the idea that a project no longer actively developed will be rewritten in rust is not? Rewriting it in Rust while continuing to actively develop the project is a lot more plausible than keeping it in C++ and being able to "maintain a stable codebase" but somehow still fix bugs. (Keeping it in C++ and continuing active development is plausible, but means the project will continue to have major vulnerabilities)

The idea is to keep it in C++ and do new development in an hypothetical Safe C++. That would ideally be significantly simpler than interface with rust or rewrite.

There is of course the "small" matter that Safe C++ doesn't exist yet, but Google analysis showing that requiring only new code to be safe is good enough, is a strong reason for developing a Safe C++.

Re: Why Safety Profiles Failed

#133

Post by rurban »

Additionally I still cannot understand why they didn't make iterators safe from the very beginning. In the alias examples some iterators must alias and some not. With safe iterators the checks would be trivial, as just the base pointers need to be compared. This could be done even at compile-time, when all iterators bases are known at compile-time.

Their argument then was that iterators are just simple pointers, not a struct of two values base + cur. You don't want to pass two values in two registers, or even on the stack. Ok, but then call them iterators, call them mere pointers. With safe iterators, you could even add the end or size, and don't need to pass begin() and end() to a function to iterate over a container or range. Same for ranges.

A iterator should have just have been a range (with a base), so all checks could be done safely, the API would look sane, and the calls could be optimized for some values to be known at compile-time. Now we have the unsafe iterators, with the aliasing mess, plus ranges, which are still unsafe and ill-designed. Thanksfully I'm not in the library working group, because I would have had heart attacks long time ago over their incompetence.

My CTL (the STL in C) uses safe iterators, and is still comparable in performance and size to C++ containers. Wrong aliasing and API usage is detected, in many cases also at compile-time.

Re: Why Safety Profiles Failed

#134

Post by CoastalCoder »

myworkinisgood wrote: post #70
SubjectToChange wrote: post #10

At this point I'm wondering if the purpose of safety profiles is simply to serve as a distraction. In other words, safety profiles are just something people can point to when the topic of memory safety comes up, that’s it. The objectives of the initiative always seemed hopelessly optimistic, if not absurd. In particular, I don't understand why littering a codebase with auto, const, constexpr, inline, [[nodiscard]], n…

[flagged]

> You are more correct than you think you are!!!

Your comment will be more interesting if you expand upon it.

Re: Why Safety Profiles Failed

#135

Post by gpderetta »

wyager wrote: post #32
alilleybrinker wrote: post #18

Earlier quoted context omitted.

Not everything will be rewritten in Rust. I've broken down the arguments for why this is, and why it's a good thing, elsewhere [1]. Google's recent analysis on their own experiences transitioning toward memory safety provide even more evidence that you don't need to fully transition to get strong safety benefits. They incentivized moving new code to memory safe languages, and continued working to actively assure the…

> Not everything will be rewritten in Rust. Yeah, but it's also not going to be rewritten in safe C++.

The point is that it doesn't need to. According to google, making sure that new code is safe is good enough.

Re: Why Safety Profiles Failed

#136

Post by CoastalCoder »

ameliaquining wrote: post #40

These considerations all seem so self-evident that I can't imagine the architects of Safety Profiles weren't aware of them; they are basically just the statement of the problem. And yet these smart people presumably thought they had some kind of solution to them. Why did they think that? What did this solution look like? I would be very interested to read more context on this.

I wonder if the unstated issue here is:

C++ is so complex that it's hard to think through all the implications of design proposals like this.

So practically speaking, the only way to prove a design change is to implement it and get lots of people to take it for a test drive.

But it's hard to find enough people willing to do that in earnest, so the only real way to test the idea is to make it part of the language standard.

Re: Why Safety Profiles Failed

#137

Post by steveklabnik »

gpderetta wrote: post #132
lmm wrote: post #118

Earlier quoted context omitted.

> yet the idea that a project no longer actively developed will be rewritten in rust is not? Rewriting it in Rust while continuing to actively develop the project is a lot more plausible than keeping it in C++ and being able to "maintain a stable codebase" but somehow still fix bugs. (Keeping it in C++ and continuing active development is plausible, but means the project will continue to have major vulnerabilities)

The idea is to keep it in C++ and do new development in an hypothetical Safe C++. That would ideally be significantly simpler than interface with rust or rewrite. There is of course the "small" matter that Safe C++ doesn't exist yet, but Google analysis showing that requiring only new code to be safe is good enough, is a strong reason for developing a Safe C++.

Safe C++ does exist today: it’s implemented in Circle. You can try it out on godbolt right now.

Re: Why Safety Profiles Failed

#138

Post by steveklabnik »

ameliaquining wrote: post #77
steveklabnik wrote: post #51

Earlier quoted context omitted.

As always with different designs from smart people, it’s about priorities. The profiles proposal focuses on a lack of annotations (I think there’s reasonable criticism that this isn’t achieved by it though…), and believing they can get 80% of the benefit for 20% of the effort (at least conceptually, obviously not those exact numbers). They aren’t shooting for full memory safety. The Safe C++ proposal asks “how do we…

What's with the "this model detects all possible errors" quote at the beginning of the post, then?

That’s a claim about dangling pointers and ownership. Profiles do not solve aliasing or concurrency, as two examples of things that Safe C++ does that are important for memory safety.

Re: Why Safety Profiles Failed

#139

Post by gpderetta »

nicoburns wrote: post #60
steveklabnik wrote: post #5

Earlier quoted context omitted.

I am pro any movement towards memory safety. Sure, I won't stop writing Rust and start moving towards C++ for this. But not everyone is interested in introducing a second toolchain, for example. Also, as this paper mentions, Safe C++ can improve C++ Rust interop, because Safe C++ can express some semantics Rust can understand. Right now, interop works but isn't very nice. Basically, I want a variety of approaches, no…

> But not everyone is interested in introducing a second toolchain, for example. Not that this invalidates your broader point about Safe C++, but this particular issue could also be solved by Rust shipping clang / a frontend that can also compile C and C++.

Having Rust directly import C++ would be excellent, but you still need to assign semantics to non-annotated C++ to safely reflect it in safe Rust. You could import it as unsafe rust, but it would be quite gnarly.

Re: Why Safety Profiles Failed

#140

Post by jerf »

crest wrote: post #58
whimsicalism wrote: post #48

Earlier quoted context omitted.

Rust has nothing on template meta programming and the type signatures you get there, though

Give the proc macro fans a little more time...

I understand the point you are making, but C++ templates really are a uniquely disastrous programming model. They can be used to pull off neat tricks, but the way those neat tricks are done is terrible.
Post reply on HN