Skip to content

Conversation

@patataofcourse
Copy link
Member

@patataofcourse patataofcourse commented Oct 23, 2023

After a quick fix for the goto loc bug (#16), here's a couple of less urgent bugfixes, these on the decompiler side. Each commit fixes one specific bug.

No more trailing spaces

Tickompiler's decompiler used to produce the following output per command (regex-like formatting used for clarity)
$operation(<$arg0>)? ($arguments.join(", "))?

This means that if there were no arguments, there would be a trailing space at the end of the command. Extra checks have been added to ensure this doesn't happen, for a cleaner experience.

Make start take priority over assets

Tickflow's decompiler had the following code:

markers[readInt()] = "start"
markers[readInt()] = "assets"

This meant that if start and assets had the same value, the output Tickflow would look like this:

// Decompiled with Tickompiler v...
#index X
assets:
tickflow_here

Seeing how start is required, but assets is not, a small change has been added to ensure read order stays the same but assets is assigned before start. This fix works for most cases, since if start matches assets, there's a chance they're both at position 0, which is the behavior Tickompiler's compiler defaults to.

Fix decompilation of Tickflow files with a bytes argument annotation

This bug, not unlike the previous one, only realistically applied to decompiling a .bin file that has previously been compiled by Tickompiler, which is why it slipped for so long. This issue would reveal itself in two different ways:

  1. Some .bin files would not decompile, giving a IllegalStateException: reached end of stream
  2. Some .bin files would decompile properly, but most strings would be empty, with some being non-empty but in the wrong place. In some edge cases some markers/labels could be missing.

This is all caused due to the decompiler's "first pass" not managing the 3 argument annotation, which indicates a bytes operation. This would cause the first pass to reach end of stream if the bytes operation was close enough to the end of the file, potentially skip over some markers, and make the position of strings remembered be offset from the actual position of the strings in the Tickflow. The first pass now properly manages bytes.

The packer had a similar error, however, due to not interpreting the contents of the Tickflow, instead copying it, the worst it could do is skip some argument annotations due to reading raw bytes as a Tickflow opint. A fix has also been added for these less frequent but equally destructive situations.

- this makes strings decompile properly if inside a bytes function
- also adds safeguard for pack - since it's functional but still holds
the same bug, just in a less harmful way
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant