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.
Comment #6 by yebblies — 2013-01-14T02:59:48Z
Comment #7 by github-bugzilla — 2013-01-14T11:49:06Z
Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/580eb165d141848658ea71ac6cba54e3023d98a8 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. https://github.com/D-Programming-Language/dmd/commit/e97e886c7a092a279bf72b1ad5e6fb63dc81b82e Merge pull request #1482 from yebblies/issue9195 Issue 9195 - Should not be able to index a pointer in safed
Comment #8 by github-bugzilla — 2013-01-16T11:50:29Z
Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3d5b45196c687b714928954b027ef2944ca0beac Fix Issue 9195 - Should not be able to index a pointer in safed Allow pointer arithmetic when using an offset that is known to be zero https://github.com/D-Programming-Language/dmd/commit/381bddf74ba9ddbd298491c182cc58043958f455 Merge pull request #1492 from yebblies/issue9195 Fix Issue 9195 - Should not be able to index a pointer in safed