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

           Summary: Is this a bug?
           Product: D
           Version: 1.051
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: anteusz@freemail.hu


--- Comment #0 from anteusz@freemail.hu 2009-11-24 13:42:41 PST ---
Compile and execute this program:
import std.stdio;
void main()
{
    goto here;
    int a=1;
    {
        int b=2;
        {
            int c=3;
            {
                int d=4;
                here:
                writefln("%d %d %d %d",a,b,c,d);
            }


        }

    }

}

Should it be 1,2,3,4?

I got
0 4226665 13 4526524

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


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au
            Summary|Is this a bug?              |Bypassing initializers with
                   |                            |goto -- Is this a bug?


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2009-11-24 20:00:14 PST ---
I don't know. That's an interesting case for safe D. In safe D, either the initializers must be executed, or bypassing them must be banned. The code below is an example of memory corruption. But as @safe isn't yet implemented (so far it only checks for use of asm, AFAIK), it's not a bug yet.

-----
class Foo { int x; }

@safe
void foo()
{
   goto xxx;
   Foo a = new Foo();
xxx:
   a.x = 8;
}

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


Matti Niemenmaa <matti.niemenmaa+dbugzilla@iki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |matti.niemenmaa+dbugzilla@i
                   |                            |ki.fi
         Resolution|                            |DUPLICATE


--- Comment #2 from Matti Niemenmaa <matti.niemenmaa+dbugzilla@iki.fi> 2009-11-25 01:38:02 PST ---
*** This issue has been marked as a duplicate of issue 602 ***

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

d-bugmail@puremagic.com wrote:

> http://d.puremagic.com/issues/show_bug.cgi?id=3549
> 
> 
> Don <clugdbug@yahoo.com.au> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |clugdbug@yahoo.com.au
>             Summary|Is this a bug?              |Bypassing initializers with
>                    |                            |goto -- Is this a bug?
> 
> 
> --- Comment #1 from Don <clugdbug@yahoo.com.au> 2009-11-24 20:00:14 PST ---
> I don't know. That's an interesting case for safe D. In safe D, either the initializers must be executed, or bypassing them must be banned. The code
below
> is an example of memory corruption. But as @safe isn't yet implemented (so far it only checks for use of asm, AFAIK), it's not a bug yet.
> 
> -----
> class Foo { int x; }
> 
> @safe
> void foo()
> {
>    goto xxx;
>    Foo a = new Foo();
> xxx:
>    a.x = 8;
> }
> 
> 

I would say that it is definitely a bug, if D is supposed to initialize memory
to zero when it is allocated.
The assignments obviously replace the initialize to zero, which makes sense
except in this example. I can only think of goto being the problem how else
could you skip the initialization.
Perhaps the compiler should initialize to zero if there is a goto even if the
initialization is overridden except for void initialization.

This should even be allowed in D1 let alone D2 or SafeD.

:) just my two cents.

Rory McGuire wrote:
> d-bugmail@puremagic.com wrote:
>  
>> http://d.puremagic.com/issues/show_bug.cgi?id=3549
>>
>>
>> Don <clugdbug@yahoo.com.au> changed:
>>
>>            What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>                  CC|                            |clugdbug@yahoo.com.au
>>             Summary|Is this a bug?              |Bypassing initializers with
>>                    |                            |goto -- Is this a bug?
>>
>>
>> --- Comment #1 from Don <clugdbug@yahoo.com.au> 2009-11-24 20:00:14 PST ---
>> I don't know. That's an interesting case for safe D. In safe D, either the
>> initializers must be executed, or bypassing them must be banned. The code 
> below
>> is an example of memory corruption. But as @safe isn't yet implemented (so far
>> it only checks for use of asm, AFAIK), it's not a bug yet.
>>
>> -----
>> class Foo { int x; }
>>
>> @safe
>> void foo()
>> {
>>    goto xxx;
>>    Foo a = new Foo();
>> xxx:
>>    a.x = 8;
>> }
>>
>>
> 
> I would say that it is definitely a bug, if D is supposed to initialize memory to zero when it is allocated.
> The assignments obviously replace the initialize to zero, which makes sense except in this example. I can only think of goto being the problem how else could you skip the initialization.
> Perhaps the compiler should initialize to zero if there is a goto even if the initialization is overridden except for void initialization.
> 
> This should even be allowed in D1 let alone D2 or SafeD.
> 
> :) just my two cents.

The quote that Stewart found makes it completely clear: this is an illegal use of goto, and it should fail to compile.
Nice and simple.