www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8838] New: Slicing static arrays should be considered unsafe ( system)

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



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

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


bearophile_hugs eml.cc changed:

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





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




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


timon.gehr gmx.ch changed:

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




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






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




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


yebblies <yebblies gmail.com> changed:

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



*** 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: -------
Dec 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Dec 26 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8838


yebblies <yebblies gmail.com> changed:

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



*** 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: -------
Jul 27 2013