search

pfalcon / ScratchABlock

Yet another crippled decompiler project
https://github.com/EiNSTeiN-/decompiler/issues/9#issuecomment-103221200
GNU General Public License v3.0
104 stars 23 forks source link

RFC for changes to PseudoC syntax #34

Open pfalcon opened 6 years ago

pfalcon commented 6 years ago

This issue is to discuss ideas on changes to PseudoC syntax - mostly to implementation aspects in ScratchABlock, but maybe general PseudoC matters too.

pfalcon commented 6 years ago

First issue is elaborating label handling. There're 2 close, but distinct issues:

  1. Currently, label syntax is ScratchABlock is rather relaxed. A label doesn't have to be an identifier. It may start with digit, and look like a number - but it's still a label, and not for example an address, and that may be confusing to beginners and lead to mistakes too. A label can actually be any sequence of non-whitespace chars.
  2. It should be emphasized that argument of goto is required to be a label. I now consider allowing it to be an address too. To achieve that, p.1 needs to be addressed first. But there can still can be ambiguities, e.g. if address starts with hexadecimal a-f. As addresses are defined to be symbolic in ScratchABlock, it's unclear how to fix this ambiguity actually (and that's of course the reason why goto was required to take a label in the first place). The motivation for allowing addresses is simplifying e.g. "disassembling to PseudoC". Of course, to simplify that completely, the parser would need to be rewritter, as currently a label is required to signify a basic block start. Ironically, if all these changes are made, it effectively enables PseudoC with implicit basic block labels, and that was one of the reasons of my grudge with LLVM IR ;-).