|[3 earlier articles]|
|Re: C/C++ obfuscator firstname.lastname@example.org (Paul Pluzhnikov) (2005-01-25)|
|Re: C/C++ obfuscator email@example.com (George Neuner) (2005-01-25)|
|Re: C/C++ obfuscator lkrupp@pssw.NOSPAM.com.INVALID (Louis Krupp) (2005-01-30)|
|Re: C/C++ obfuscator firstname.lastname@example.org (Ira Baxter) (2005-01-30)|
|Re: C/C++ obfuscator email@example.com (Paul Pluzhnikov) (2005-02-03)|
|Re: C/C++ obfuscator firstname.lastname@example.org (2005-02-03)|
|Re: C/C++ obfuscator email@example.com (Paul Pluzhnikov) (2005-02-06)|
|Re: C/C++ obfuscator firstname.lastname@example.org (Louis Krupp) (2005-02-06)|
|From:||Paul Pluzhnikov <email@example.com>|
|Date:||6 Feb 2005 14:59:35 -0500|
|References:||05-01-074 05-01-110 05-02-023|
> Am I missing something?
I think you are.
To make a commercial product, you need your obfuscator to produce code
that compiles with *all* the widely-available compilers, but such
compilers are often bad at compiling the results of machine
transformation of the original source.
Consider the EDG front-end and C++-generating back-end, which we (and
many others, including AFAIK SGI's Pro64 you mentioned) use.
It has special cases for VC6.0, 7.0 and 7.1, and for gcc. Yes,
reconstructed code is (in some cases) different for each of the above
It does not officially support and does not handle some of the
Yet in the past 6 month we filed tens of problem reports, where a
trivial source is reconstructed back in almost exactly the same form,
yet the compiler refuses to accept and compile the reconstructed code.
Just in case someone mis-understands me, the bugs are not in the EDG
code; it's the compilers that are buggy.
So, as always, the devil is in the details.
In order to understand recursion you must first understand recursion.
Return to the
Search the comp.compilers archives again.