Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!compilers-sender
From: rf@mcc.comg (Ron Guilmette)
Newsgroups: comp.compilers
Subject: Re: Encripted source as an ANDF
Message-ID: <3949@ima.ima.isc.com>
Date: 20 May 89 15:32:16 GMT
Sender: compilers-sender@ima.ima.isc.com
Reply-To: rf@mcc.comg (Ron Guilmette)
Lines: 109
Approved: compilers@ima.UUCP
Posted-Date: Sat, 20 May 89 10:32:16 CDT

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.

I think that this is the best and most portable solution that anybody
is ever going to find, but it just won't catch on for at least three 
reasons.

First, when describing this approach to potential buyers (i.e. osf and
friends) people will have to use the word "source" somewhere in the
description (even though the type of "source" we are talking about is
*not* usable in the same way as "normal" source is).  Just using this
word will scare off a lot of people who have emotional rather than
rational responses to the word (i.e. managers and other people in
positions of authority and ignorance).

Second, this solution is just not "flashy" enough.  It would be hard for
OSF to come forward before the trade press and hold a press conference
and give out press releases saying how they are the good guys because they
are seeking out and applying advanvced state-of-the-art technologies, newly
developed as a product of painstaking cutting-edge research if, in the
final analysis, all they were announcing was "uglified" source code.
Let's face it... anybody could have thought of that.

Third, you cannot forget the "Beltway Bandit" syndrome.  Obviously, some
company is going to get a lot of money from OSF (not to mention the PR
value) by having the winning proposal.  Whatever company that is will have
thousands (perhaps millions) of reasons for insisting, at every opportunity
and on all occasions the the emperor *does* in fact have clothes.  (This
part ought to be fun to watch from the outside, especially as the arguments
get more and more ridiculous).

------

Regarding "uglified" source code, it should be noted that "uglification"
could really be a very intense process, going far beyond anything that
you might at first think of.  I have great confidence that we in this
industry can think up innumerable way in which to "uglify" source code.
Many of the fundamental techniques of "uglification" could be garnered
directly form student programs (and, unfortunately, many programs written
by "professionals"... and I use the term loosely... as does everyone else).
Yes, we already have a large repertoire of ugliness to draw from.  We can
easily make code ugly; we just have trouble making it (actually) pretty
(rather than just well indented).

Some uglification transformations were noted by Dale Worley in the original
posting (i.e. removing comments, changing identifiers).  I would like
to mention just a few more.

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.
This causes all sorts of essentially one way transformations and the output
tends heavily towards ugly.

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.  This transformation alone should reasonably
prevent any theft of ideas (or code) given that it is guaranteed to make
the resulting code totally incomprehensible.  Given the current state of
the art in the area of restructuting tools, this is also (effectively) a
one way transformation for many languages.  This transformation is also
a particularly good candidate for use in an ANDF generator because the
semantics of the original source code may be strictly manitained, and
the transformation itself should have little or no effect on the quality
of the *final* generated (machine-dependent) code (assuming that even
modest optimizations take place in the ANDF compiler(s)).

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.  In each of
these cases, the construct in question is just a convenient shorthand
notation which can be done away with via a sort of macro substitution.
Again, there should be no effect on final code quality.

The suggestion of yet further uglification techniques is left as an exercise
for the reader.  If you can't think of any then look at somebody else's
code.  If you look long enough, you're bound to see something which makes
code harder to maintain (although the original author is likely to disagree).

As a free service to the OSF, I will start collecting a list of uglifications.
If they arrive in sufficient number, I will summarize to the net.

[The author sent this followup shortly afterwards. -John]

Sorry.  But I just had to post a follow up note and mention one
more important source code uglification technique which couldd be
used for an ANDF generator.

The particular uglification technique I'm thinking of only works
for C++, but it is quite simple.  All you have to do to get a
really ugly (but semantically equivalent) version of a hunk of C++
source code is to run it through AT&T's cfront translator (which
generates totally obscure C code).  If you have never looked at
the output generated by cfront, you are really missing something!
Now we're really talking ugly!  Fortunately (as already well
demonstrated) we are also talking *portable* ugly.

// Ron Guilmette  -  MCC  -  Experimental Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg
--
Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU
Plausible paths are { decvax | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request