www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10201] New: "= void" initialization should not be allowed in safe

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10201

           Summary: "= void" initialization should not be allowed in  safe
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: m.strashun gmail.com



Compiles in 2.063:

------------
 safe void foo()
{
   int x = void;
}
------------

Reporting because Andrei has clearly stated this is not intentional:
http://forum.dlang.org/post/ko55pi$2upp$1 digitalmars.com

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10201




Additional explanation - it does report an error if initialized value is a
pointer or contains a pointer. It does not report an error if value has
disabled constructor though.

So it is not that dangerous in that sense, but can be used to workaround some
guarantees provided by disabled constructor. Prohibiting all void initalizers
in  safe may be both more simple and consistent.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10201


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra gmail.com





 So it is not that dangerous in that sense, but can be used to workaround some
 guarantees provided by disabled constructor. Prohibiting all void initalizers
 in  safe may be both more simple and consistent.


It is dangerous in the sense that for a struct that is not POD, you are
violating its internal integrity, at which point, it has no way to guarantee
the safety of its own internal operations.

I mentioned this in
https://github.com/D-Programming-Language/phobos/pull/1434#issuecomment-21644766
with the example:

//----
struct S
{
    private size_t index;
    private ubyte[1] arr;

    ref ubyte get()  trusted
    {
        return arr.ptr[index];
    }
}

void main()  safe
{
    S s = void;
    ubyte a = s.get();
}
//----

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