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

Safe C++ proposal is not being continued

sibellavia.lol

Post reply on HN
Print view View original

171–180 of 226 posts

Re: Safe C++ proposal is not being continued

#171

Post by jmull »

seanbax wrote: post #165
jmull wrote: post #76

Earlier quoted context omitted.

The analysis you link to is insufficient. E.g., the first case is "Inferring aliasing". He presents some examples and states, "The compiler cannot infer a function’s aliasing requirements from its declaration or even from its definition." But why not? The aliasing requirements come directly from vector. If the compiler has those then determining the aliasing requirements of those functions is straightforward. Now, ma…

The Profiles authors are the ones claiming this uses local analysis only: https://news.ycombinator.com/item?id=41942126 They are clear that Profiles infers everything from function types and not function bodies. Obviously that won't work, but that's what they say.

In that post (I think your own?) it says, "Local analysis only. It's not looking in function definitions."

But local analysis means analysis of function definitions. At least it does to me. I can't think of what else it could mean. I think there must be some aspect of people talking past each other here, using the same words to mean different things.

Further, I don't think local analysis of the code comprising a function means throwing away the results of that analysis rather than passing it up the line to the analysis of callers of the function. E.g., local analysis of std::sort would establish its aliasing limitations, which would be available to analysis of the body of "f1" from the example in the paper (the results of which, in turn, would be available to callers of f1).

Now, I don't know if that's actually feasible/workable without the "heavy" annotation that C++ profiles wants to forbid. That's the key question to me.

Re: Safe C++ proposal is not being continued

#172

Post by hyperman1 »

WalterBright wrote: post #123
IshKebab wrote: post #106

Earlier quoted context omitted.

I think D failed to gain widespread traction for other reasons though: 1. The use of garbage collection. If you accept GC there are many other languages you can use. If you don't want GC the only realistic option was C++. Rust doesn't rely on GC. IIRC GC in D is optional in some way, but the story always felt murky to me and that always felt like a way of weaseling out of that problem - like if I actually started wri…

Using D does not require a garbage collector. You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations. D has a lot of very useful features. Memory safety features are just one aspect of it. > The awkward standard library schism. ??? Don't underestimate the backing of a large and powerful organization.

I've been on the edge to try out D a few times now, and always decided for No in the end.

For me, it was missing presence in the IT news that did it. D might be great, but it makes no noise.

Rust or go had a lot of articles and blog posts going deep into specific posts, appearing at a regular rate. They tended to appear on e.g this hacker news, or reddit, etc... This caused a drip feed of tutoring, giving me a slow but steady feel for these languagee. There were people tirelessly correcting misinformation. There were non stop code examples of people doing stuff with the language, proving the language usable in all kind of situations.

Re: Safe C++ proposal is not being continued

#173

Post by tialaramex »

pizlonator wrote: post #61
tialaramex wrote: post #57

Earlier quoted context omitted.

Yes I can be specific. Firstly, you need composition. Rust's safety composes. The safe Rust library for farm animals from Geoff, the safe Rust library for cooking recipes by Alice and the safe Rust library for web server by Bert together with my safe program code adds up to my safe Rust farm foods web site. By having N profiles, where N is intended to be at least five and might grow arbitrarily and be user extensible…

I think the point is that folks will incrementally move their code towards having all profiles enabled, and that's sort of fundamental if the goal is to give folks with C++ codebases an incremental path to safety. So I don't buy your first and second points. > Which comes to the third part. Once you start down this path, as they found, you realise you actually want a borrowck. That's a bold statement. It might be tru…

So you agree then, it's technically not as good. With a lot of extra work that nobody has signed up to do, and some of which is speculative, they can't quite get to where Safe C++ was when proposed.

Re: Safe C++ proposal is not being continued

#174

Post by fl0ki »

IshKebab wrote: post #143
WalterBright wrote: post #123

Earlier quoted context omitted.

Using D does not require a garbage collector. You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations. D has a lot of very useful features. Memory safety features are just one aspect of it. > The awkward standard library schism. ??? Don't underestimate the backing of a large and powerful organization.

> You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations. Yes but people wanted a language where you can't use GC. > ??? "Which standard library should I use?" is not a question most languages have: https://stackoverflow.com/q/693672/265521 Surely... you were aware of this problem? Maybe I misunderstood the "???". > Don't underestimate the backing of a large a…

"The best thing about standard libraries is that there are so many to choose from"

Re: Safe C++ proposal is not being continued

#175

Post by steveklabnik »

jmull wrote: post #161
dwattttt wrote: post #83

Earlier quoted context omitted.

I imagine it's (implicitly?) referring to avoiding whole-of-program analysis. For example, given a declaration int* func(int* a); What's the relationship between the return value and the input? You can't know without diving into 'func' itself; they could be the same pointer or it could return a freshly allocated pointer, without getting into the even more esoteric options. Trying to solve this without recursively ana…

> avoiding whole-of-program analysis Why, though? Perhaps it's unfeasibly complex? But if that's the argument, then that's an argument that needs to be made. The paper sets out to refute the idea that C++ already has the information needed for safety analysis, but the examples throw away most of the information C++ does have, without explanation. I can't really take it seriously.

In general, there are three reasons to avoid whole program analysis:

1. Complexity. This manifests as compile times. It takes much longer.

2. Usability. Error messages are poor, because changes have nonlocal effects.

3. Stability. This is related to 2. Without requirements expressed in the signature, changes in the body change the API, meaning keeping APIs stable is much harder.

There’s really a simple reason why it’s not fully feasible in C++ though: C++ supports separate compilation. This means the whole program is not required to be available. Therefore you don’t have the whole program for analysis.

Re: Safe C++ proposal is not being continued

#176

Post by ModernMech »

lelanthran wrote: post #96
zozbot234 wrote: post #67

Earlier quoted context omitted.

> So far I've always succeeded without using "unsafe" or indices, but it drags down productivity. There is a common perception that Rust is less productive than competing languages, but empirical research by Google and others has found this to be wrong. Rust just shifts the effort earlier in the development phase, where the costs are often orders of magnitude lower. You may spend a few hours struggling with the borro…

> Rust just shifts the effort earlier in the development phase, where the costs are often orders of magnitude lower. That works fantastically when you're rewriting something - you already have the idea and final product nailed down. It works poorly when you don't have everything nailed down and might switch a lot of stuff around, or remove stuff that isn't needed, etc.

I think that's actually where Rust can shine -- it's very good at refactoring, so when you move stuff around and cut things out that you don't need, the compiler tells you exactly how to put everything back together and what exactly needs to be changed. As the codebase grows, refactorability becomes crucial, because refactors are risky and can fail, causing major schedule disruptions. High code velocity achieved early on by ignoring reference lifetimes and borrows and type checking early on might feel good, but these features are a detriment later one when the project needs to start making guarantees.

Re: Safe C++ proposal is not being continued

#177

Post by maleldil »

krater23 wrote: post #147
AlotOfReading wrote: post #30

Earlier quoted context omitted.

It doesn't show up in the online videos, but there was a huge contingent of people at that fireside chat wanting a reasonable safety story for C++. The committee simply doesn't have representation from those people and don't seem to understand why it's an existential risk to the language community. The delivery timelines are so long here that anything not standardized soon isn't going to arrive for a decade or more.…

Sorry man, but I work since 2012 in professional security development in C/C++. Normally no one talks anymore about things like buffer overflows, use after free,... since years. Everyone uses tools to check for this, and in the end it's cheaper than using Rust. The attack vectors we talk about are logic errors and wrong usage of crypto. Things that can happen with Bash, C/C++, Rust and any other language and that you…

> Normally no one talks anymore about things like buffer overflows, use after free,... since years

Some of the biggest vulnerabilities of recent years (e.g. Heartbleed) were out-of-bounds access. The most common vulnerability sources are things that are impossible in Rust, but cannot be fully solved via C++ static checkers.

Re: Safe C++ proposal is not being continued

#178

Post by seanbax »

jmull wrote: post #171
seanbax wrote: post #165

Earlier quoted context omitted.

The Profiles authors are the ones claiming this uses local analysis only: https://news.ycombinator.com/item?id=41942126 They are clear that Profiles infers everything from function types and not function bodies. Obviously that won't work, but that's what they say.

In that post (I think your own?) it says, "Local analysis only. It's not looking in function definitions." But local analysis means analysis of function definitions. At least it does to me. I can't think of what else it could mean. I think there must be some aspect of people talking past each other here, using the same words to mean different things. Further, I don't think local analysis of the code comprising a func…

  template
    _GLIBCXX20_CONSTEXPR
    inline void
    sort(_RandomAccessIterator __first, _RandomAccessIterator __last)
    {
      // concept requirements
      __glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept)
      __glibcxx_function_requires(_LessThanComparableConcept::value_type>)
      __glibcxx_requires_valid_range(__first, __last);
      __glibcxx_requires_irreflexive(__first, __last);

      std::__sort(__first, __last, __gnu_cxx::__ops::__iter_less_iter());
    }
That's the definition of std::sort. What aliasing information can be gleaned from local analysis of the function? Absolutely nothing.

Re: Safe C++ proposal is not being continued

#179

Post by seanbax »

Panzerschrek wrote: post #97

The mentioned proposal isn't really that great. It basically tries to make C++ to Rust by blindly copying many its ideas. Many of them aren't strictly necessary to achieve safety in C++. There are different proposals for safety, which are way smaller and simpler than this one.

Which ideas aren't strictly necessary to achieve safety in C++?
Post reply on HN