Re: Encripted source as an ANDF

harvard!cs.utah.edu!esunix!bpendlet (Bob Pendleton)
Wed, 24 May 89 08:57:46 mdt

          From comp.compilers

Related articles
Re: Encripted source as an ANDF rf@mcc.comg (1989-05-20)
Re: Encripted source as an ANDF albaugh@dms.UUCP (1989-05-23)
Re: Encripted source as an ANDF henry@zoo.toronto.edu (1989-05-24)
Re: Encripted source as an ANDF harvard!cs.utah.edu!esunix!bpendlet (1989-05-24)
Re: Encripted source as an ANDF jeffb@grace.cs.washington.edu (1989-05-24)
Re: Encripted source as an ANDF bpendlet@esunix.uucp (1989-05-24)
Re: Encripted source as an ANDF rfg@mcc.com (1989-05-27)
Re: encripted source as an ANDF rfg@mcc.com (1989-05-27)
Re: Encripted source as an ANDF kbierman@sun.com (1989-05-30)
Re: encripted source as an ANDF henry@zoo.toronto.edu (1989-05-31)
| List of all articles for this month |

Date: Wed, 24 May 89 08:57:46 mdt
From: harvard!cs.utah.edu!esunix!bpendlet (Bob Pendleton)

rf@mcc.comg (Ron Guilmette):
> worley@compass.com (Dale Worley) writes:
>>The most interesting ANDF-type work I've seen is the concept of
>>"shrouded source code", that is, compilable source that has been
>>deliberately uglified by removing comments, renaming variables, etc.


> First, in the case of C (or C++) one of the best techniques for rapidly
> removing the mantainability from a piece of source code (that is assuming
> that there was any to being with) is to preprocess it with the C
> preprocessor.


> Another very effective uglifing transformation is to perform comprehensive
> de-structuring, i.e. the conversion of all loops and well structured if and
> switch/case statements into the most degenerative possible equivalent forms
> using GOTO statements.


> For C, other good "semantics preserving" one way transformations include
> the elimination of all typedef statements, and the elimination of all
> enum type declarations/definitions and enum type constants.


So as a general rule all "uglifications" must preserve semantics.


Ok, now lets make all temporaries explicit and break up expressions
into sequences of statements containing only binary or ternary
operations like "x op= y," "x = y op z," and "if(x)goto y."


Lets make all address arithmetic and dereferencing operations
explicit.


Now lets do some loop folding, move invariant code out of loops, and
common subexpression elimination.


Is that ugly enough for you?


Doesn't this process sound familiar? By the time you have the "source"
code in this uglified form you have done most of the work of compiling
it. If you are careful your uglifying transformations can not only
preserve the semantics of the original program, they can be machine
independent.


Mapping the partially compiled intermediate code, er... I must mean
uglified code, into machine code for a specific architecture without
messing up the semantics is hard. But then that has always been the
hard part of implementing standards compliant compilers.


Bob P.
[From harvard!cs.utah.edu!esunix!bpendlet (Bob Pendleton)]
--


Post a followup to this message

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