A brief introduction to C++'s model for type- and resource-safety [pdf]

Re:A brief introduction to C++'s model for type- and resourc... by nickpsecurity on Friday January 15, 2016 @08:45PM (#10913773)

In "hardware" as a minimal processor extension as I said? Pointer checks, etc take almost nothing in HW. Garbage collection schemes have a bigger hit and more complex integration. Hence, having his published report for details to add to collection of lightweight schemes out there for C++ or even another language that might benefit later.

That sort of thing happens more than you know in CompSci. Example: One method for Oberon and Java appliances I pulled right out of an old Scheme CPU paper that was also impractical then. Also found a correct-by-construction HW method in same one. ;)

[ Parent | on HN ]

Re:A brief introduction to C++'s model for type- and resourc... by pcwalton on Friday January 15, 2016 @08:49PM (#10913784)

Specifically, how do you do use after free detection in hardware without garbage collection?

[ Parent | on HN ]

Re:A brief introduction to C++'s model for type- and resourc... by nickpsecurity on Friday January 15, 2016 @11:48PM (#10914297)

I should've clarified that my statement assumes his model works as advertised, then notes that the pointer checks are efficient in hardware. I couldn't be sure if he was detecting or preventing use-after-free with what would be in compiler and what in runtime. Here's the things I was looking at:

"supports the general thesis that garbage collection is neither necessary nor sufficient for quality software. This paper describes the techniques used to eliminate dangling pointers and to ensure resource safety."

"Every object on the free store (heap, dynamic store) must have exactly one owner [pointer/reference]"

"set the ownership bit when a value returned from new is assigned"

"use delete whenever a pointer with the ownership bit is set goes out of scope"

Sounds similar to what I read in Rust guide, esp one-per-location and scope part. Those and other rules appeared to make it easy for checks to prevent or catch use-after-free. If so, then my keep it around for hardware suggestion could lead to acceleration work. If I misread the paper or goals of ownership model, then my suggestion would've only led to accelerating... whatever safety it was trying to enforce.

Did that clear it up for you? Or did you spot where I went wrong? Could go either way given it was a quick read for me.

[ Parent | on HN ]