Compilation strategy

[Walter Bright]

On 12/16/2012 11:08 PM, Jonathan M Davis wrote:
> The concept of .di files and their ilk is fundamentally broken precisely
> because they're trying to strip what's in the file. That's what causes the
> problems.

What is and what isn't in a .di is entirely under the user's control.


>> Object files are resistant to reverse engineering because most of the
>> information is gone.
> True, but they can stll be reverse engineered,

I know what I'm talking about with this. The only time they get reverse 
engineered is when somebody really really REALLY wants to do it, an expert is 
necessary to do the job, and it's completely impractical for larger sets of 
files. You cannot build a tool to do it, it must be done by hand, line by line. 
It's the proverbial turning of hamburger back into a cow.

A binary format of the source code, however, is EASY to turn back into source 
code, and it's EASY to write a tool to do it automatically, and complete idiots 
can successfully run that tool and reverse engineer it by pushing a button.

You cannot even begin to compare the difficulty levels between the two.

> and if the problem is that
> companies don't want 3rd parties looking at their code, then a binary format
> has obfuscated it and possibly solved that problem.

No, it has not obfuscated it at all.

> Object files do make it
> harder, but they can still be reverse engineered, so it really becomes a
> question of what it takes to satisfy the folks who think that not giving the
> whole information in a .d or .cpp file somehow protects their code (since it
> doesn't really). And if a binary format can do that (as it seems to in Java
> land), then that seems like a far better solution, because then we can leave
> all of the information in there that inlining and CTFE need in order to do
> their jobs. With .di files, we'll never get that.

Java developers tried to "obfuscate" their code by distributing them as .class 
files, and someone promptly wrote a free tool to turn .class files back into 
source code.

No such tool exists for object code, and never has. That should be a pretty 
strong indication of its possibilities.

If you want to obfuscate your code, the way to do it is with the PIMPL idiom. 
That works, it works now, and has a long track record of working for statically 
compiled languages.