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

21–30 of 233 posts

Re: Why Safety Profiles Failed

#21

Post by o11c »

akira2501 wrote: post #15
o11c wrote: post #13

Earlier quoted context omitted.

Dealing with malloc/free is trivial and cheap - just give every allocated object a couple of reference counts. The hard part is figuring out which words of memory should be treated as pointers, so that you know when to alter the reference counts. Most C programs don't rely on all the weird guarantees that C mandates (relying on asm, which is also problematic, is probably more common), but for the ones that do it is q…

> just give every allocated object a couple of reference counts. Works great with a single thread.

Multi-threaded refcounts aren't actually that hard?

There's overhead (depending on how much you're willing to annotate it and how much you can infer), but the only "hard" thing is the race between accessing a field and and changing the refcount of the object it points to, and [even ignoring alternative CAS approaches] that's easy enough if you control the allocator (do not return memory to the OS until all running threads have checked in).

Note that, in contrast the the common refcount approach, it's probably better to introduce a "this is in use; crash on free" flag to significantly reduce the overhead.

Re: Why Safety Profiles Failed

#22

Post by SubjectToChange »

steveklabnik wrote: post #3

Really glad to see this thorough examination of the weaknesses of profiles. Safe C++ is a really important project, and I hope the committee ends up making the right call here.

>...I hope the committee ends up making the right call here.

WG21 hasn't been able to solve the restrict type qualifier, or make a better alternative, in over twenty years. IMO, hoping that WG21 adequately solves Safe C++ is nothing more than wishful thinking, to put it charitably.

Re: Why Safety Profiles Failed

#23

Post by JoshTriplett »

o11c wrote: post #17
tialaramex wrote: post #11

Earlier quoted context omitted.

> "No mutable aliases" is a mistake; it prevents many useful programs. Does it? You didn't list any. It certainly prevents writing a tremendous number of programs which are nonsense.

The entirety of Rust's `std::cell` is a confession that yes, we really do need mutable aliases. We just pretend they the aliases aren't mutable except for a nanosecond around the actual mutation.

Cells still don't allow simultaneous mutable aliases; they just allow the partitioning of regions of mutable access to occur at runtime rather than compile time.

Re: Why Safety Profiles Failed

#24

Post by acbits »

o11c wrote: post #13
murderfs wrote: post #8

Earlier quoted context omitted.

virtual address space is cheap, but changing it is massively expensive. If you have to do a TLB shootdown on every free, you're likely going to have worse performance than just using ASan.

Dealing with malloc/free is trivial and cheap - just give every allocated object a couple of reference counts. The hard part is figuring out which words of memory should be treated as pointers, so that you know when to alter the reference counts. Most C programs don't rely on all the weird guarantees that C mandates (relying on asm, which is also problematic, is probably more common), but for the ones that do it is q…

https://github.com/acbits/reftrack-plugin

I wrote a compiler extension just for this issue since there wasn't any.

Re: Why Safety Profiles Failed

#25

Post by loeg »

Section 6 seems to propose adding essentially every Rust feature to C++? Am I reading that right? Why would someone use this new proposed C++-with-Rust-annotations in place of just Rust?

Re: Why Safety Profiles Failed

#26

Post by steveklabnik »

loeg wrote: post #25

Section 6 seems to propose adding essentially every Rust feature to C++? Am I reading that right? Why would someone use this new proposed C++-with-Rust-annotations in place of just Rust?

Here’s the actual proposal: https://safecpp.org/draft.html

It explains its own motivation.

Re: Why Safety Profiles Failed

#27

Post by steveklabnik »

SubjectToChange wrote: post #22
steveklabnik wrote: post #3

Really glad to see this thorough examination of the weaknesses of profiles. Safe C++ is a really important project, and I hope the committee ends up making the right call here.

>...I hope the committee ends up making the right call here. WG21 hasn't been able to solve the restrict type qualifier, or make a better alternative, in over twenty years. IMO, hoping that WG21 adequately solves Safe C++ is nothing more than wishful thinking, to put it charitably.

I am intimately familiar with the dysfunctions of various language committees.

I never said it would be easy, or probable. But I’m also the kind who hopes for the best.

Re: Why Safety Profiles Failed

#28

Post by steveklabnik »

o11c wrote: post #13
murderfs wrote: post #8

Earlier quoted context omitted.

virtual address space is cheap, but changing it is massively expensive. If you have to do a TLB shootdown on every free, you're likely going to have worse performance than just using ASan.

Dealing with malloc/free is trivial and cheap - just give every allocated object a couple of reference counts. The hard part is figuring out which words of memory should be treated as pointers, so that you know when to alter the reference counts. Most C programs don't rely on all the weird guarantees that C mandates (relying on asm, which is also problematic, is probably more common), but for the ones that do it is q…

The borrow checker works irrespective of the heap. Memory safety involves all pointers, not just ones that own a heap allocation.

Re: Why Safety Profiles Failed

#29

Post by ijustlovemath »

loeg wrote: post #25

Section 6 seems to propose adding essentially every Rust feature to C++? Am I reading that right? Why would someone use this new proposed C++-with-Rust-annotations in place of just Rust?

Because the millions of lines of existing C++ aren't going anywhere. You need transition capability if you're ever gonna see widespread adoption. See: C++'s own adoption story; transpiling into C to get wider adoption into existing codebases.

Re: Why Safety Profiles Failed

#30

Post by favorited »

I know Sean said on Twitter that he probably won't submit this to WG21, but I wish he would... It is a fantastic rebuttal of certain individual's continued hand-waving about how C++ is safe enough as-is.
Post reply on HN