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

           Summary: array.ptr in @safe code
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: code@klickverbot.at


--- Comment #0 from David Nadlinger <code@klickverbot.at> 2013-10-05 11:29:36 PDT ---
The following program is @safe, yet reads from an invalid memory location:
---
@safe:

ubyte oops(ubyte[] b) {
    return *b.ptr;
}

void main() {
    oops(new ubyte[0]);
    // - or -
    auto b = new ubyte[42];
    oops(b[$ .. $]);
}
---

To keep memory safety guarantees, we would at least have to make sure that the element after the end of an array never belongs to a different, valid allocation.

Brought up by Denis Shelomovskij in a discussion on GitHub.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #1 from David Nadlinger <code@klickverbot.at> 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
------- You are receiving this mail because: -------

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



--- Comment #2 from David Nadlinger <code@klickverbot.at> 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 issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #3 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-10-05 17:24:56 PDT ---
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 @trusted like some folks have been trying to do in druntime (and incorrectly in some cases - e.g. bug# 11168), since then the function making the call would likely have to be marked as @trusted or @system quite often when calling C functions, as many C functions take arrays. And many that don't take arrays still take pointers of another kind, and taking the address of something is @system, so it makes me wonder if we should just not mark any C functions as anything but @system. It's already arguably bad to mark them as @trusted when we don't have their source code, and when you pretty much can't call them from @safe code anyway, it becomes rather pointless to try and mark them as @trusted.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #4 from David Nadlinger <code@klickverbot.at> 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 @trusted

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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #5 from Jonathan M Davis <jmdavisProg@gmx.com> 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 be true. So, regardless of ptr, it's a problem. Though with druntime using @trusted: on whole modules in some places, I find it hard to believe that we're not screwing this up in several places. 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 functions normally), I'd be tempted to argue that marking C functions with @trusted should simply not be done under normal circumstances.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #6 from David Nadlinger <code@klickverbot.at> 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 functions normally), I'd be
> tempted to argue that marking C functions with @trusted should simply not be
> done under normal circumstances.

I invite you to take up this argument with the people who are working hard to make Phobos usable in @safe code. ;)

Jokes aside, C functions that are @safe should be marked as such, otherwise this will just lead to client code being marked as @trusted. And this not only shifts the problem, but as the expected fan-in of a druntime declaration is larger than one, makes the problem *worse* because now that difficult decision has to be made in several places instead of just one.

I agree that marking functions as trusted (external or not) comes with a high potential for mistakes, but I'd argue that the best way to avoid making them is to help with reviewing the related pull requests (and the existing code once new pitfalls such as the reentrancy issue are discovered).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 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 and mark things as @trusted just so that something will work in @safe code. Certainly, it's something that we need to be very careful about in reviews - especially when the compiler clearly considers a number of things @safe which aren't.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------