checkedint call removal

[Andrei Alexandrescu via Digitalmars-d]

On 8/2/14, 11:55 AM, Walter Bright wrote:
> On 8/2/2014 8:08 AM, Andrei Alexandrescu wrote:
>> On 8/2/14, 5:44 AM, Artur Skawina via Digitalmars-d wrote:
>>>    auto fx(ubyte* p, size_t len) @safe {
>>>        assert_(len>0);
>>>        if (len>=1)
>>>           return p[0];
>>>        return -1;
>>>     }
>>
>> As an aside I think it's a bug that this function passes @safe. It
>> should not be
>> able to safely dereference the pointer because it may be e.g. just
>> past the end
>> of the array. Has this been submitted as a bug? -- Andrei
>>
>
> There's more than one way to think about it. We could disable all
> pointer dereferences, but another way is to fall back on the presumption
> that arguments to @safe functions must themselves be valid.
>
> I.e. is this @safe:
>
>     &array[length]
>
> ? How could a pointer past the end be created in @safe code?

The way I see it, if we allow pointer dereference in @safe code, we must 
make sure that @safe code can never produce a past-the-end pointer.

Assume we choose that, there's still murky ground:

@system fun(int[] p) {
    gun(p.ptr + p.length);
}

@safe gun(int* p) {
    if (p) *p = 42;
}

This passes semantic checking but is unsafe and unsafety is in the @safe 
code. Well, that's fine, we might say. The problem is this works against 
our stance that "inspect @system code by hand, @safe code will take care 
of itself". The problem is that pointers just past the end have this 
weird property "the pointer is okay but not for dereferencing".


Andrei