Path: utzoo!attcan!uunet!husc6!spdcc!ima!compilers-sender
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.compilers
Subject: Re: Encripted source as an ANDF
Message-ID: <3963@ima.ima.isc.com>
Date: 24 May 89 04:25:40 GMT
Sender: compilers-sender@ima.ima.isc.com
Reply-To: henry@zoo.toronto.edu (Henry Spencer)
Lines: 41
Approved: compilers@ima.UUCP

Upon reflection, it occurs to me that there is a minor problem with using
obfuscated source as an ANDF.  This problem turns major for most other
ANDF concepts I can think of.  Consider:  at some level, one must leave the
insides of libraries to the target system.  At the very least, how to do
a system call is system-specific.  Moreover, different systems often have
good reason to fiddle with the insides of, say, printf, to adapt it to
the facilities and characteristics of the particular system.  One really
wants an ANDF-distributed program to use the target's library, not one
that the program hauls along.

PROBLEM:  what to do about things like putc(), which are macros -- that 
is, are normally expanded before one generates obfuscated source, or
tokenized source, or compiler intermediate form -- but must interface
correctly with the local library?  This is a hassle even today on systems
where some code is distributed as object modules to be linked on the
target system:  one cannot improve stdio, for example, without risk of
breaking such code.  The insides of those macros are really part of the
target system's library and should be expanded on the target system.

Worse, it's not just function-like macros that are affected, but even
plain old numeric constants, which can appear in places like array
dimensions.  That means you can't just pretend that putc() is really a
function and have the ANDF translator on the target machine do the
code expansion -- that doesn't work for BUFSIZ.  To make BUFSIZ match
that of the target machine (which it must if you want the target's
setbuf() to work right), you have to do the preprocessing on the target.

One can imagine programming practices that would avoid some specific
cases of these problems, but it's a nasty problem in general.  Especially
if you want to be able to apply it to existing portable programs.

It seems to me that this kills any ANDF scheme which is not essentially
based on obfuscated (but non-preprocessed) source.

                                     Henry Spencer at U of Toronto Zoology
                                 uunet!attcan!utzoo!henry henry@zoo.toronto.edu
--
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