|[4 earlier articles]|
|Re: C/C++ obfuscator email@example.com (George Neuner) (2005-01-25)|
|Re: C/C++ obfuscator lkrupp@pssw.NOSPAM.com.INVALID (Louis Krupp) (2005-01-30)|
|Re: C/C++ obfuscator firstname.lastname@example.org (Ira Baxter) (2005-01-30)|
|Re: C/C++ obfuscator email@example.com (Paul Pluzhnikov) (2005-02-03)|
|Re: C/C++ obfuscator firstname.lastname@example.org (2005-02-03)|
|Re: C/C++ obfuscator email@example.com (Paul Pluzhnikov) (2005-02-06)|
|Re: C/C++ obfuscator firstname.lastname@example.org (Louis Krupp) (2005-02-06)|
|From:||Louis Krupp <email@example.com>|
|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|
>>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.
Return to the
Search the comp.compilers archives again.