Bug 9195 – Should not be able to index a pointer in safed
Status
RESOLVED
Resolution
FIXED
Severity
major
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-12-22T11:42:00Z
Last change time
2013-01-16T11:50:29Z
Keywords
accepts-invalid, pull
Assigned to
yebblies
Creator
dmitry.olsh
Comments
Comment #0 by dmitry.olsh — 2012-12-22T11:42:23Z
Pointer arithmetic limitation is too dam easy to side step. In fact I did it accidentaly.
The snippet shows the problem in its full glory:
@safe uint* glorious(uint * ptr, size_t offset)
{
return &ptr[offset];
}
//correctly can't be @safe
/*@safe*/ @trusted uint* casual(uint * ptr, size_t offset)
{
return ptr+offset;
}
@safe void main()
{
uint[] arr = [1, 2, 3, 4];
assert(*casual(arr.ptr, 3) == 4);
assert(*glorious(arr.ptr, 3) == 4);
assert(glorious(arr.ptr, 0xdead_beaf) == casual(arr.ptr, 0xdead_beaf));
}
This undermines the whole promise of memory safety in SafeD - if you can index raw pointers you no safer then with direct pointer arithmetic.
Comment #1 by issues.dlang — 2012-12-30T03:58:32Z
I don't see the problem here. The pointer arithmetic is in @trusted code. It's up to the programmer - not the compiler - to verify the safety of the code in that case. And all of the unsafe operations are in @trusted code. If you don't want this to happen, then don't mark a function as @trusted when it doesn't make sense to. This code is a problem simply because code which had no business being marked as @trusted was marked as @trusted. What would you expect to work differently about this?
Comment #2 by dmitry.olsh — 2012-12-30T04:20:34Z
(In reply to comment #1)
> I don't see the problem here. The pointer arithmetic is in @trusted code. It's
> up to the programmer - not the compiler - to verify the safety of the code in
> that case. And all of the unsafe operations are in @trusted code. If you don't
> want this to happen, then don't mark a function as @trusted when it doesn't
> make sense to. This code is a problem simply because code which had no business
> being marked as @trusted was marked as @trusted. What would you expect to work
> differently about this?
It's not @trusted. casual is a doing a pointer atirhmetic just fine.
But see 'glorious' function in this example. It is does the same pointer arithmetic but it's marked @safe and main is @safe! All compiles and runs, it's a bug in @safety.
Comment #3 by issues.dlang — 2012-12-30T14:35:00Z
> It's not @trusted. casual is a doing a pointer atirhmetic just fine.
But casual is marked as @trusted, so I don't see any problem there at all.
As for glorious, what pointer arithmetic is it doing? I just see it indexing an array, which would be bounds checked. Though actually, it looks like it's taking the address of a local variable, which is supposed to be @system. So, _that_ is a bug, but I don't see any pointer arithmetic here which is marked with @safe when it should be @system. It's the & which is the problem.
Comment #4 by simen.kjaras — 2012-12-30T15:34:22Z
> As for glorious, what pointer arithmetic is it doing? I just see it indexing an
array, which would be bounds checked.
Look again. It's not indexing an array, it's indexing a pointer.
Comment #5 by issues.dlang — 2012-12-30T17:26:28Z
> Look again. It's not indexing an array, it's indexing a pointer.
Hmmm. Yes, you're right. It's indexing a pointer. I guess that that's currently considered @safe, though underneath the hood, it's really no different from pointer arithmetic. Dereferencing the pointer should be fine, and ptr[0] should be fine for that same reason, but ptr[x] could be doing who-knows-what and isn't really any different from *(ptr + x), so that should be considered @system and isn't.
So, I'd say that the problem is that indexing a pointer is considered @safe when it shouldn't be, presumably because it's not explicit pointer arithmetic. The fact that you were talking about pointer arithmetic threw me off, since the explicit pointer arithmetic _isn't_ @safe, and I guess that Walter got thrown off in a similar way when he made pointer arithmetic @system.