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

A Usable C++ Dialect That Is Safe Against Memory Corruption

ithare.com

Post reply on HN
Print view View original

71–80 of 103 posts

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#71

Post by nobugs »

duneroadrunner wrote: post #42

If anyone is really interested in this sort of thing, I suggest you take a look at SaferCPlusPlus[1]. It is "A Usable C++ Dialect That Is Safe Against Memory Corruption" (including data races). And it already exists. And I think it's better than this proposed dialect in that most of the (safety) restrictions are enforced without requiring extra tooling, and it's much less restrictive. Most existing C++ code can be co…

I happen to like quite a few things from it, but... there is a Big Fat Hairy Difference(tm) between "safe" and merely "safer". Make it "guaranteed to be safe" (which will most likely require tooling) rather than merely "safer" - and I will be the first one to promote it myself :-). Also - it would be gr8 to reduce the number of different concepts developer needs to remember about while programming. In OP (assuming that tooling does exist) it is quite simple: there are only 3 concepts, with 2 of them ('naked' and 'owning'=unique_ptr) being already very familiar; OTOH, current implementation of SaferCPlusPlus reminds me of ALGOL68 - where it was possible to specify _everything_, but choosing the right thing was so time-consuming that it never really flew.

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#72

Post by nobugs »

kolpa wrote: post #27
saagarjha wrote: post #12

Earlier quoted context omitted.

If you're not being facetious, then really, not much. You really can't go wrong with smart pointers unless you explicitly try to access the memory it handles rather than going through its normal interface (e.g., not using get()). Shared pointers are basically reference counted just like many other language handle memory management.

> > as long as we’re following these rules/ guidelines If that's an assumption, it's not worth much. A safe language is one that enforces the rules, not one that hopes the program authors self-enforce.

Of course. The point is that (IF there is enough interest in the idea) these rules are simple enough (in particular, they're inherently local, i.e. don't require analysis to go beyond one single function) to be enforced by a tool (say, built on top of Clang-tidy).

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#73

Post by blub »

nobugs wrote: post #71
duneroadrunner wrote: post #42

If anyone is really interested in this sort of thing, I suggest you take a look at SaferCPlusPlus[1]. It is "A Usable C++ Dialect That Is Safe Against Memory Corruption" (including data races). And it already exists. And I think it's better than this proposed dialect in that most of the (safety) restrictions are enforced without requiring extra tooling, and it's much less restrictive. Most existing C++ code can be co…

I happen to like quite a few things from it, but... there is a Big Fat Hairy Difference(tm) between "safe" and merely "safer". Make it "guaranteed to be safe" (which will most likely require tooling) rather than merely "safer" - and I will be the first one to promote it myself :-). Also - it would be gr8 to reduce the number of different concepts developer needs to remember about while programming. In OP (assuming th…

SaferCPlusPlus has two big issues which prevent me from using it: confusing class naming and too many concepts.

I do like the ideas it builds on, and I will probably implement a simplified version for my needs...

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#74

Post by blub »

saagarjha wrote: post #60
scott_s wrote: post #39

Earlier quoted context omitted.

> Do you mean std::vector and at()? No, std::array was added in C++11: http://en.cppreference.com/w/cpp/container/array

std::array has its size fixed at compile time, so there's no reason for you to do have to do bounds checking…

char buffer[100] also has a fixed size and is responsible for most buffer overflow bugs :)

array::at is just as mandatory as vector::at IMO.

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#75

Post by steveklabnik »

nobugs wrote: post #70
devit wrote: post #34

This works, although the downside compared to Rust is that soft pointer validity is checked at runtime, meaning that a program that compiles can still randomly fail at runtime and that performance is worse due to the checks. The key idea and massive difference from standard C++ is that object destruction is delayed until a "quiescient state" happens in what is a reframing of RCU [ https://en.wikipedia.org/wiki/Read-c…

> that performance is worse due to the checks. I'd argue that use cases for 'soft pointers' are about the same as that of Rust's RC , which also incurs runtime costs (very briefly - there is no magic here, neither with Rust). > The key idea and massive difference from standard C++ is that object destruction is delayed until a "quiescient state" happens If you're speaking about OP - clarification: it is not "object de…

Do you happen to have a citation for (i)? That's very interesting!

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#76

Post by pjmlp »

steveklabnik wrote: post #75
nobugs wrote: post #70

Earlier quoted context omitted.

> that performance is worse due to the checks. I'd argue that use cases for 'soft pointers' are about the same as that of Rust's RC , which also incurs runtime costs (very briefly - there is no magic here, neither with Rust). > The key idea and massive difference from standard C++ is that object destruction is delayed until a "quiescient state" happens If you're speaking about OP - clarification: it is not "object de…

Do you happen to have a citation for (i)? That's very interesting!

Yes, NVidia specially designs their new GPGPUs for C++ execution.

"Volta and Cuda C++" - http://cppcast.com/2017/09/olivier-giroux/

CppCon 2017: Olivier Giroux "Designing (New) C++ Hardware”

https://www.youtube.com/watch?v=86seb-iZCnI

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#77

Post by nobugs »

pjmlp wrote: post #76
steveklabnik wrote: post #75

Earlier quoted context omitted.

Do you happen to have a citation for (i)? That's very interesting!

Yes, NVidia specially designs their new GPGPUs for C++ execution. "Volta and Cuda C++" - http://cppcast.com/2017/09/olivier-giroux/ CppCon 2017: Olivier Giroux "Designing (New) C++ Hardware” https://www.youtube.com/watch?v=86seb-iZCnI

Yep, this one. On CPPCON17, Olivier Giroux has said: "[when designing Volta,] we were literally quoting C++ standard to each other".

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#78

Post by pjmlp »

saagarjha wrote: post #59
pdpi wrote: post #55

Earlier quoted context omitted.

Which means you have to design around it. You can definitely run into problems with cyclical shared_ptr dependencies

Well, you have to do this for every language that does reference counting.

Either that, or have a cycle collector in addition to the normal reference counting optimizations.

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#79

Post by pjmlp »

jasonhanley wrote: post #25

I feel like stuff like this is why golang and rust were created. (edit: Forgot about Rust, sorry!)

Well, they were mostly created, because the alternatives to C and C++ ended up loosing their market share, so current generations aren't usually aware of what came before.

Go is anything hardly new versus what Algol 68, Pascal or Oberon derivative would offer.

Likewise the best part of Rust is their work on how to make affine types from Cyclone, ATS and others into more developer friendly and productive language features, while following the traditional rules of other safe systems languages.

Since it is easier to introduce new languages than bring back old ones, here we are.

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#80

Post by nobugs »

kbenson wrote: post #65
nobugs wrote: post #62

Earlier quoted context omitted.

-fwrapv should fix it (no warranties of any kind, batteries not included).

IIRC this particular case was only seen on a specific version of one compiler for MacOS that was provided with extra patches, so it's at first glance less of a problem than it originally looks. That said, I don't think it was doing anything illegal according to the standard (no an expert on this), and as compiled software and a library, the reach of that case may be larger than we might otherwise assume. There are un…

To the best of my knowledge, the only compilers to exploit overflows, are GCC/Clang (and those commercial compilers I know about, explicitly said that they are NOT going to exploit signed-overflow UB, IIRC I heard it from MSVC and xlC). And for GCC/Clang, -frapw achieves the same thing. Still, I agree that things change, but this kind of behaviour won't be easy to change (at all); OTOH, I am going to campaign to remove this UB from the standard altogether (there is no real reason for this UB, at least for the platforms 99.9% of developers are working on).
Post reply on HN