Related articles |
---|
[4 earlier articles] |
Re: C/C++ obfuscator gneuner2@comcast.net (George Neuner) (2005-01-25) |
Re: C/C++ obfuscator lkrupp@pssw.NOSPAM.com.INVALID (Louis Krupp) (2005-01-30) |
Re: C/C++ obfuscator idbaxter@semdesigns.com (Ira Baxter) (2005-01-30) |
Re: C/C++ obfuscator ppluzhnikov@charter.net (Paul Pluzhnikov) (2005-02-03) |
Re: C/C++ obfuscator robert.hundt@gmail.com (2005-02-03) |
Re: C/C++ obfuscator ppluzhnikov@charter.net (Paul Pluzhnikov) (2005-02-06) |
Re: C/C++ obfuscator lkrupp@pssw.com (Louis Krupp) (2005-02-06) |
From: | Louis Krupp <lkrupp@pssw.com> |
Newsgroups: | comp.compilers |
Date: | 6 Feb 2005 15:00:07 -0500 |
Organization: | Posted via Supernews, http://www.supernews.com |
References: | 05-01-074 05-01-087 05-01-093 05-01-103 05-02-005 |
Keywords: | C, tools |
Posted-Date: | 06 Feb 2005 15:00:07 EST |
<snipped, carefully>
>>The source to be shipped would have to be tested on any compiler the
>>customer might use ...
>
>
> Not necessarily: if the original code desn't use
> arcane/not-well-supported language features, then one can test 1
> or 2 compilers, and expect all other combinations to work.
>
> If some compiler/OS combinations turn out not to work, future
> customers may be warned against using those.
>
> The above approach is pretty much what everyone who ships source
> does; shipping obfuscated source is not that different.
I would disagree somewhat and say that the point of writing clean,
predictable code is not so that you don't have to test on all
platforms you intend to support; the point is that when you do all
that testing, the code works, and your life is easier.
Louis
Return to the
comp.compilers page.
Search the
comp.compilers archives again.