Issue 9195 - Should not be able to index a pointer in safed #1482

Merged
merged 1 commit into from Jan 14, 2013

Projects

None yet

4 participants

Member

This prevents indexing a pointer in @safe code unless the index is known at compile time to be zero.

http://d.puremagic.com/issues/show_bug.cgi?id=9195

@yebblies yebblies Fix Issue 9195 - Should not be able to index a pointer in safed
This prevents indexing a pointer in @safe code unless the index is known at compile time to be zero.
580eb16
Owner

nice!

@WalterBright WalterBright merged commit e97e886 into dlang:master Jan 14, 2013

1 check passed

default Pass: 10
Details
Member

Should we also allow ptr+0 in @safe code?

Owner
braddr commented Jan 16, 2013

Ideally any expression involving ptr that after const folding is equal to ptr still. But I don't expect there's a lot of those other than ptr[0]. ptr+0 might be next most likely and ptr+var where var is known to be 0 a distant third. and ptr+expr where expr ctfe'ly evaluates to 0 and even more distant forth?

Member

I don't think I've every seen *(ptr+0) in real code...

and ptr+expr where expr ctfe'ly evaluates to 0 and even more distant forth?

We can't evaluate expr using ctfe in most contexts.

We could allow *([1,2,3].ptr + 2) if we really wanted to, or even

uint x;
auto b = *((cast(ubyte*)&x)+3);

This could be done by calculating a 'safe offset' for each pointer expression and checking the range.

Owner

Is this done after inlining? At that point there could be quite a few instances of p[0].

Member

No, before inlining. If you do it after then some code will only compile with -inline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment