"Ironclad C++, A Library-Augmented Type-Safe Subset of C++" by Christian DeLozier et al:
http://repository.upenn.edu/cis_reports/982/

It's a strict subset of C++ plus added some libraries and some static verifiers. The purpose is to have a safer C++. It has some similarities with D.

There are many small differences between C++ and Ironclad C++, one of them is that all pointers must be smart pointers. It also uses a precise garbage collection.

In my opinion what's most interesting is what it does for Stack Deallocation Safety, it uses dynamic lifetime checking, with two smart pointers, page 5-8:

>Prior work on preventing use-after-free errors has introduced some notion of a local pointer [10, 18], but these efforts have been focused on purely static enforcement through sophisticated program analyses. Local pointers in Ironclad C++ combine static enforcement and dynamic checking, providing flexibility and simplifying the necessary analysis.<

>Local pointers record the lower bound on addresses that they may point to. Through a combination of static restrictions and dynamic checks, these local pointers are allowed to point only to heap-allocated values or values at the same level or above in the call stack.<

The paper explains the various cases: assign from ptr<T> into lptr<T>, assign from lptr<T> into ptr<T>, and assign from lptr<T> into lptr<T>.

So with a mix of run-time tests and a small amount of static analysis the code is safe and fast enough. It seems a simple enough idea.

Bye,
bearophile

On 8/3/2013 4:32 PM, bearophile wrote:
> The paper explains the various cases: assign from ptr<T> into lptr<T>, assign
> from lptr<T> into ptr<T>, and assign from lptr<T> into lptr<T>.
>
> So with a mix of run-time tests and a small amount of static analysis the code
> is safe and fast enough. It seems a simple enough idea.

The problem with different pointer types is, of course, what do you do with functions that take pointers as arguments?

On 08/04/2013 01:55 AM, Walter Bright wrote:
> On 8/3/2013 4:32 PM, bearophile wrote:
>> The paper explains the various cases: assign from ptr<T> into lptr<T>,
>> assign
>> from lptr<T> into ptr<T>, and assign from lptr<T> into lptr<T>.
>>
>> So with a mix of run-time tests and a small amount of static analysis
>> the code
>> is safe and fast enough. It seems a simple enough idea.
>
> The problem with different pointer types is, of course, what do you do
> with functions that take pointers as arguments?
>

Why would that be a problem?

On 8/3/2013 5:49 PM, Timon Gehr wrote:
> On 08/04/2013 01:55 AM, Walter Bright wrote:
>> On 8/3/2013 4:32 PM, bearophile wrote:
>>> The paper explains the various cases: assign from ptr<T> into lptr<T>,
>>> assign
>>> from lptr<T> into ptr<T>, and assign from lptr<T> into lptr<T>.
>>>
>>> So with a mix of run-time tests and a small amount of static analysis
>>> the code
>>> is safe and fast enough. It seems a simple enough idea.
>>
>> The problem with different pointer types is, of course, what do you do
>> with functions that take pointers as arguments?
>>
>
> Why would that be a problem?

Consider the canonical example:

    void* foo(void *p) { return p; }

Do you write an overload for each kind of pointer?

On 08/04/2013 04:06 AM, Walter Bright wrote:
> On 8/3/2013 5:49 PM, Timon Gehr wrote:
>> On 08/04/2013 01:55 AM, Walter Bright wrote:
>>> On 8/3/2013 4:32 PM, bearophile wrote:
>>>> The paper explains the various cases: assign from ptr<T> into lptr<T>,
>>>> assign
>>>> from lptr<T> into ptr<T>, and assign from lptr<T> into lptr<T>.
>>>>
>>>> So with a mix of run-time tests and a small amount of static analysis
>>>> the code
>>>> is safe and fast enough. It seems a simple enough idea.
>>>
>>> The problem with different pointer types is, of course, what do you do
>>> with functions that take pointers as arguments?
>>>
>>
>> Why would that be a problem?
>
> Consider the canonical example:
>
>      void* foo(void *p) { return p; }
>
> Do you write an overload for each kind of pointer?

No, you use lptr<void> because it is the most specialized type that works.

On 8/3/2013 7:08 PM, Timon Gehr wrote:
> On 08/04/2013 04:06 AM, Walter Bright wrote:
>> On 8/3/2013 5:49 PM, Timon Gehr wrote:
>>> On 08/04/2013 01:55 AM, Walter Bright wrote:
>>>> On 8/3/2013 4:32 PM, bearophile wrote:
>>>>> The paper explains the various cases: assign from ptr<T> into lptr<T>,
>>>>> assign
>>>>> from lptr<T> into ptr<T>, and assign from lptr<T> into lptr<T>.
>>>>>
>>>>> So with a mix of run-time tests and a small amount of static analysis
>>>>> the code
>>>>> is safe and fast enough. It seems a simple enough idea.
>>>>
>>>> The problem with different pointer types is, of course, what do you do
>>>> with functions that take pointers as arguments?
>>>>
>>>
>>> Why would that be a problem?
>>
>> Consider the canonical example:
>>
>>      void* foo(void *p) { return p; }
>>
>> Do you write an overload for each kind of pointer?
>
> No, you use lptr<void> because it is the most specialized type that works.

Then the pointer coming out is more specialized than the pointer that went in?

On 08/04/2013 04:28 AM, Walter Bright wrote:
> On 8/3/2013 7:08 PM, Timon Gehr wrote:
>> On 08/04/2013 04:06 AM, Walter Bright wrote:
>>> On 8/3/2013 5:49 PM, Timon Gehr wrote:
>>>> On 08/04/2013 01:55 AM, Walter Bright wrote:
>>>>> On 8/3/2013 4:32 PM, bearophile wrote:
>>>>>> The paper explains the various cases: assign from ptr<T> into
>>>>>> lptr<T>,
>>>>>> assign
>>>>>> from lptr<T> into ptr<T>, and assign from lptr<T> into lptr<T>.
>>>>>>
>>>>>> So with a mix of run-time tests and a small amount of static analysis
>>>>>> the code
>>>>>> is safe and fast enough. It seems a simple enough idea.
>>>>>
>>>>> The problem with different pointer types is, of course, what do you do
>>>>> with functions that take pointers as arguments?
>>>>>
>>>>
>>>> Why would that be a problem?
>>>
>>> Consider the canonical example:
>>>
>>>      void* foo(void *p) { return p; }
>>>
>>> Do you write an overload for each kind of pointer?
>>
>> No, you use lptr<void> because it is the most specialized type that
>> works.
>
> Then the pointer coming out is more specialized than the pointer that
> went in?

Yes, but as far as I understood it you can assign lptr<void> back to ptr<void> implicitly by paying for a runtime check. It's what D will be doing with T* <-> ref T, right?

(The general problem is easily addressed at the type system level using some kind of parametric polymorphism, but they don't do that. D's inout is a somewhat failed attempt that gets quite close to solving the issue for the mutability qualifiers.)

On 8/3/2013 7:41 PM, Timon Gehr wrote:
> Yes, but as far as I understood it you can assign lptr<void> back to ptr<void>
> implicitly by paying for a runtime check. It's what D will be doing with T* <->
> ref T, right?

I thought the idea was to use the type system to avoid runtime checks.


> (The general problem is easily addressed at the type system level using some
> kind of parametric polymorphism, but they don't do that. D's inout is a somewhat
> failed attempt that gets quite close to solving the issue for the mutability
> qualifiers.)

I don't believe it is easily addressed or someone would have done so by now.

On Sunday, 4 August 2013 at 02:41:18 UTC, Timon Gehr wrote:
> D's inout is a somewhat failed attempt

Why?

>
> Consider the canonical example:
>
>     void* foo(void *p) { return p; }
>
> Do you write an overload for each kind of pointer?

Doesn't D already have that problem with its immutable/const pointers?