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
