https://issues.dlang.org/show_bug.cgi?id=11176
--- Comment #16 from Nick Treleaven ---
> it should be safe to allow comparing a .ptr with another pointer, so long as
> .ptr is not dereferenced
I think I've pushed this point enough. Instead I expect it is acceptable to add
a function to std.arra
https://issues.dlang.org/show_bug.cgi?id=11176
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #17 fro
http://d.puremagic.com/issues/show_bug.cgi?id=11176
--- Comment #2 from David Nadlinger 2013-10-05 11:31:51
PDT ---
The easiest fix would be to just disallow accessing the .ptr property in @safe
code. There probably wouldn't be much reason to use it in the first place
anyway.
--
Configure is
http://d.puremagic.com/issues/show_bug.cgi?id=11176
--- Comment #1 from David Nadlinger 2013-10-05 11:30:23
PDT ---
Forgot to mention: The above snippet compiles fine using DMD 2.064 Git
(a35bd9e) on Linux x86_64.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
http://d.puremagic.com/issues/show_bug.cgi?id=11176
Jonathan M Davis changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
--- Comment #3
http://d.puremagic.com/issues/show_bug.cgi?id=11176
--- Comment #4 from David Nadlinger 2013-10-05 17:29:59
PDT ---
@J(In reply to comment #3)
> An interesting side note to marking .ptr on arrays as unsafe would be that it
> would make it kind of pointless to mark a lot of C functions as @trus
http://d.puremagic.com/issues/show_bug.cgi?id=11176
--- Comment #5 from Jonathan M Davis 2013-10-05 18:02:00
PDT ---
> I think you are missing something here: A C function taking an array by
> pointer and length or a pointer to a zero-terminated array can never be
> @trusted.
Ah, that would
http://d.puremagic.com/issues/show_bug.cgi?id=11176
--- Comment #6 from David Nadlinger 2013-10-05 18:37:22
PDT ---
(In reply to comment #5)
> And with so many C
> functions taking pointers of one variety of another (combined with the fact
> that we don't have the actual source code for C func
http://d.puremagic.com/issues/show_bug.cgi?id=11176
--- Comment #7 from Jonathan M Davis 2013-10-05 22:22:38
PDT ---
(In reply to comment #6)
True enough, but I think that it highlights how careful we need to be with
marking functions @trusted. Sometimes, I think that we're too quick to try a
https://issues.dlang.org/show_bug.cgi?id=11176
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--
https://issues.dlang.org/show_bug.cgi?id=11176
hst...@quickfur.ath.cx changed:
What|Removed |Added
Keywords||safe
--
https://issues.dlang.org/show_bug.cgi?id=11176
Nick Treleaven changed:
What|Removed |Added
CC||ntrel-...@mybtinternet.com
--- Comment #8 f
https://issues.dlang.org/show_bug.cgi?id=11176
--- Comment #9 from Kenji Hara ---
One another way I can think is, array.ptr property would add a hidden check
`arr.length != 0` under @safe code, then returns `null` instead when the length
is 0.
@safe ubyte* oops1(ubyte[] b) {
return b.ptr;
}
https://issues.dlang.org/show_bug.cgi?id=11176
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #10 f
https://issues.dlang.org/show_bug.cgi?id=11176
--- Comment #11 from Kenji Hara ---
It was just an idea. Indeed, it would be a case that the conditional behavior
is worse than simple disabling.
I noticed that we already have equivalent but safer way &arr[0]. Under @safe
attribute, it checks the '
https://issues.dlang.org/show_bug.cgi?id=11176
--- Comment #12 from Steven Schveighoffer ---
(In reply to Kenji Hara from comment #11)
> I noticed that we already have equivalent but safer way &arr[0]. Under @safe
> attribute, it checks the 'arr' boundaries and throws RangeError if the index
> ac
https://issues.dlang.org/show_bug.cgi?id=11176
--- Comment #13 from Nick Treleaven ---
(In reply to Steven Schveighoffer from comment #10)
> I think you have to just disallow ptr
> access in @safe code. That's the only thing that's checkable at
> compile-time, and will prevent a @safe inference
https://issues.dlang.org/show_bug.cgi?id=11176
--- Comment #14 from Steven Schveighoffer ---
(In reply to Nick Treleaven from comment #13)
> The following is safe:
> assert(elem.ptr is null);
>
> Even this is safe:
> i = tmp.ptr - trailing.ptr;
>
> Both of these are from Phobos. We only need to
https://issues.dlang.org/show_bug.cgi?id=11176
--- Comment #15 from Jonathan M Davis ---
In general, we should not make something @system unless it needs to be, but
it's not like we guaranteed that the compiler wasn't conservative in what it
considered to be @safe. So, losing out on some potentia
https://issues.dlang.org/show_bug.cgi?id=11176
Walter Bright changed:
What|Removed |Added
Summary|array.ptr in @safe code |array.ptr in @safe code may
https://issues.dlang.org/show_bug.cgi?id=11176
Walter Bright changed:
What|Removed |Added
Keywords||pull
--- Comment #18 from Walter Bright ---
https://issues.dlang.org/show_bug.cgi?id=11176
--- Comment #19 from Steven Schveighoffer ---
I added a possible mechanism to allow safe equivalent to arr.ptr. Please see
PR: https://github.com/dlang/druntime/pull/1592
--
https://issues.dlang.org/show_bug.cgi?id=11176
Walter Bright changed:
What|Removed |Added
CC||and...@erdani.com
--- Comment #20 from Walte
https://issues.dlang.org/show_bug.cgi?id=11176
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
Issue 11176 - array.ptr in @safe code may point past end of array
--
https://issues.dlang.org/show_bug.cgi?id=11176
--- Comment #22 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dmd
https://github.com/dlang/dmd/commit/02d7ebe3f37b3584cfd0443630d3493f49411c0e
Merge pull request #5860 from WalterBright/fix11176
--
https://issues.dlang.org/show_bug.cgi?id=11176
Steven Schveighoffer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
greenify ---
> I think this is already fixed, not sure why it didn't get closed
Because it seems like the bugzilla integration doesn't like whitespace:
"fix Issue 11176 - array.ptr in @safe code may point past end of array"
--
28 matches
Mail list logo
