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


--- 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: -------
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


--- 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: -------
Oct 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
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


--- 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: -------
Oct 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
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


--- 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: -------
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


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