If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
NEW : We have got a new blog where we post some interesting SWF internals info.
List of issues#2474 Goto statements (manually inserted) incorrectly decompiled
Author: 
JPEXS
JPEXSDate created:
Type: bug
Visibility: Everybody
Assigned to:
Labels: AS1/2AS3Decompilation
State: closed 
> What steps will reproduce the problem?
Compile the following AS1 code in FFDec without the §§goto,
then manually insert jump into code in P-code editor to mimic §§goto statement.
(Or use attached goto_simple.swf file)
```
var v = 5;
if(v > 1)
{
trace("a");
if(v > 2)
{
trace("goto");
§§goto(label);
}
trace("b");
}
else
{
trace("c");
}
trace("d");
if(v > 3)
{
trace("e");
if(b > 5)
{
trace("f");
label:
trace("g");
}
trace("h");
}
else
{
trace("i");
}
trace("end");
```
> What is the expected output? What do you see instead?
I see this after decompilation:
```
var v = 5;
if(v > 1)
{
trace("a");
if(v > 2)
{
trace("goto");
addr44:
trace("g");
trace("h");
}
else
{
trace("b");
}
§§goto(addr51);
}
else
{
trace("c");
}
trace("d");
if(v > 3)
{
trace("e");
if(b > 5)
{
trace("f");
}
§§goto(addr44);
}
else
{
trace("i");
}
addr51:
trace("end");
```
The block "b" continues to block "end".
Expected: Block "b" should continue to block "d".
> What version of the product are you using? Is it "nightly build"? Which operating system
do you have?
23.0.1 nightly 3210, Windows 11
> Please provide any additional information below. If the problem is related to a SWF
file, attach it here, otherwise we can't help you.
goto_simple.swf (168 B)In 24.0.1 nightly 3221,
it decompiles as:
var v = 5;
if(v > 1)
{
trace("a");
if(v > 2)
{
trace("goto");
addr44:
trace("g");
addr46:
trace("h");
}
else
{
trace("b");
addr26:
trace("d");
if(v > 3)
{
trace("e");
if(b > 5)
{
trace("f");
§§goto(addr44);
}
§§goto(addr46);
}
else
{
trace("i");
}
}
trace("end");
return;
}
trace("c");
§§goto(addr26);
Which has more than single one goto, but the control flow is correct in this case. Block
"b" continues to block "end", others seem to match too.
The decompiler uses "backward gotos" to previously defined label.
I would be better if it preffered forward gotos.
State: new→upgraded
State: upgraded→closed