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

           Summary: Slicing static arrays should be considered unsafe
                    (@system)
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: jmdavisProg@gmx.com


--- Comment #0 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-10-17 13:45:53 PDT ---
This code compiles just fine

int[] foo() @safe
{
    int[5] a;
    return a[];
}

void main()
{}

It really shouldn't. What it's doing is _not_ memory safe. And while implementing issue# 7087 would fix this particular case, it doesn't fix the problem in general, because all it takes is adding another function to the mix, and the compiler can't catch it:

int[] foo() @safe
{
    int[5] a;
    return bar(a);
}

int[] bar(int[] a) @safe
{
    return a;
}

void main()
{}

Taking the slice of a static array is really no different from taking the address of a local variable, and that's already @system, so slicing a static array should be as well.

Honestly, I wish that static arrays didn't implicitly slice when being passed to functions taking dynamic arrays precisely because of how dangerous it is, and the fact that the implicit conversion makes it really easy to miss, but at least if it were marked @system, then it couldn't happen in @safe code, and it would be harder to have bugs like in the code above.

-- 
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=8838


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #1 from bearophile_hugs@eml.cc 2012-10-17 15:23:41 PDT ---
(In reply to comment #0)

> Taking the slice of a static array is really no different from taking the address of a local variable, and that's already @system, so slicing a static array should be as well.

This is a big change in D, so before going this route I suggest to think well about this topic.

-- 
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=8838



--- Comment #2 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-10-17 16:35:57 PDT ---
> This is a big change in D, so before going this route I suggest to think well
about this topic.

The thing is that it _isn't_ memory safe. There's no question of that. So, per the definition of @safe, it has no business being @safe. It needs to be @system. If it's not, then SafeD is broken. I don't see how anyone could argue otherwise.

Yes, it's breaking change in the cases where people actually use @safe, but there's no way around that, and honestly, I suspect that most people don't mark their code @safe anyway, and it's only applicable to where static arrays are sliced, so I don't know how much code will really be broken. For folks who use static arrays and @safe heavily, it'll break a lot. For most other people, probably nothing.

Regardless, I don't see how we can _not_ make this change given what @safe is supposed to do.

-- 
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=8838


timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch


--- Comment #3 from timon.gehr@gmx.ch 2012-10-17 16:42:44 PDT ---
(In reply to comment #2)
> > This is a big change in D, so before going this route I suggest to think well
> about this topic.
> 
> The thing is that it _isn't_ memory safe. There's no question of that. So, per
> the definition of @safe, it has no business being @safe. It needs to be
> @system. If it's not, then SafeD is broken. I don't see how anyone could argue
> otherwise.
> ...

The code segment must be rejected, but what makes it unsafe is the escaping. Banning the slicing is not very precise.

-- 
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=8838



--- Comment #4 from bearophile_hugs@eml.cc 2012-10-17 16:47:12 PDT ---
(In reply to comment #3)

> The code segment must be rejected, but what makes it unsafe is the escaping. Banning the slicing is not very precise.

Region analysis is not one of the design goals of D, unfortunately. But a little of such analysis will be useful in the D front-end.

-- 
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=8838



--- Comment #5 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-10-17 16:57:55 PDT ---
> The code segment must be rejected, but what makes it unsafe is the escaping. Banning the slicing is not very precise.

It's exactly what happens with taking the address of a local variable. It's an error if the compiler can determine that it's escaping, but it's @system regardless. And because the compiler _can't_ guarantee that the reference isn't escaping, it really has no choice but to make it @system to take the address or slice in the first place. Doing otherwise would mean that it's possible to have memory corruption issues when only using @safe code, which would be violating @safe.

-- 
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=8838


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pszturmaj@tlen.pl


--- Comment #6 from yebblies <yebblies@gmail.com> 2012-12-27 02:24:46 EST ---
*** Issue 6844 has been marked as a duplicate of this issue. ***

-- 
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=8838


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com
           Severity|enhancement                 |normal


-- 
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=8838


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acehreli@yahoo.com


--- Comment #7 from yebblies <yebblies@gmail.com> 2013-07-28 16:41:54 EST ---
*** Issue 7087 has been marked as a duplicate of this issue. ***

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