Re: Taking an AST back into C

vbdis@aol.com (VBDis)
5 Dec 2004 21:33:28 -0500

          From comp.compilers

Related articles
Taking an AST back into C nb_no_spam@synthcom.com (Neil Bradley) (2004-11-28)
Re: Taking an AST back into C Martin.Ward@durham.ac.uk (Martin Ward) (2004-12-01)
Re: Taking an AST back into C torbenm@diku.dk (2004-12-01)
Re: Taking an AST back into C vbdis@aol.com (2004-12-01)
Re: Taking an AST back into C vbdis@aol.com (2004-12-05)
Re: Taking an AST back into C vbdis@aol.com (2004-12-05)
Re: Taking an AST back into C vbdis@aol.com (2004-12-11)
Re: Taking an AST back into C Martin.Ward@durham.ac.uk (Martin Ward) (2004-12-11)
Re: Taking an AST back into C vbdis@aol.com (2004-12-13)
| List of all articles for this month |

From: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 5 Dec 2004 21:33:28 -0500
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 04-12-008
Keywords: decompile
Posted-Date: 05 Dec 2004 21:33:28 EST

torbenm@diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=) schreibt:


>Control structure isn't so bad, as loops and if-then-else constructs
>are fairly easy to detect.


One of the usually ignored or inappropriately "solved" problems are
complex conditional expressions, with short circuit evaluation. It's
not so easy to determine the range of conditional expressions, and how
to translate it back into high level code.


>The main problem is data structures, as different data structures are
>translated into similar code.


That's true, but not the hardest problem. Often it's undecidable what
data type a pointer actually refers to, be it a structure, or the
first member of that structure, or the first element in an array
etc. It's a real puzzle to make all subroutine argument data types
match all related calls, in detail when typecasts were used in the
original code.


DoDi


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.