[Issue 3549] Bypassing initializers with goto -- Is this a bug?

[d-bugmail]

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


Don  changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au
Summary|Is this a bug?  |Bypassing initializers with
   ||goto -- Is this a bug?


--- Comment #1 from Don  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: ---

[Issue 3549] Bypassing initializers with goto -- Is this a bug?

[d-bugmail]

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


Matti Niemenmaa  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||matti.niemenmaa+dbugzi...@i
   ||ki.fi
 Resolution||DUPLICATE


--- Comment #2 from Matti Niemenmaa  
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: ---

[Issue 3549] Bypassing initializers with goto -- Is this a bug?

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=3549

Walter Bright  changed:

   What|Removed |Added

Version|1.051   |D1

--

Re: [Issue 3549] Bypassing initializers with goto -- Is this a bug?

[Rory McGuire]

d-bugm...@puremagic.com wrote:
 
> http://d.puremagic.com/issues/show_bug.cgi?id=3549
> 
> 
> Don  changed:
> 
>What|Removed |Added
> 
>  CC||clugd...@yahoo.com.au
> Summary|Is this a bug?  |Bypassing initializers with
>||goto -- Is this a bug?
> 
> 
> --- Comment #1 from Don  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.

Re: [Issue 3549] Bypassing initializers with goto -- Is this a bug?

[Don]

Rory McGuire wrote:

d-bugm...@puremagic.com wrote:
 

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


Don  changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au
Summary|Is this a bug?  |Bypassing initializers with
   ||goto -- Is this a bug?


--- Comment #1 from Don  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.