www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11176] New: array.ptr in safe code

reply d-bugmail puremagic.com writes:
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



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: -------
Oct 05 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11176




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: -------
Oct 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11176




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: -------
Oct 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11176


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



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 -

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: -------
Oct 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11176




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


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: -------
Oct 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11176




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: -------
Oct 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11176




PDT ---


 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: -------
Oct 05 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11176




PDT ---


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: -------
Oct 05 2013