Related articles |
---|
[3 earlier articles] |
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) |
From: | henry@zoo.toronto.edu |
Date: | Wed, 31 May 89 05:11:04 EDT |
Newsgroups: | comp.compilers |
In-Reply-To: | <3991@ima.ima.isc.com> |
>> It seems to me that this kills any ANDF scheme which is not essentially
>> based on obfuscated (but non-preprocessed) source.
>
>In case you missed my point, I disagree very strongly. You should be
>able to do a (partial) preprocessing step on the "development" system...
I should have been clearer. Note the word "essentially", though. I admit
I didn't think of partial preprocessing, which could be useful.
Do remember, though, that ANSI C in particular encourages rather more use
of macros with potentially implementation-specific bodies than older C
practice. Not to say that partial preprocessing won't work, but a rather
larger number of identifiers are going to have to be marked "hands off".
[From henry@zoo.toronto.edu]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.