Compilation strategy

[Paulo Pinto]

On Monday, 17 December 2012 at 08:21:43 UTC, Walter Bright wrote:
> 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.
>

Really?!

http://www.hopperapp.com/

I really like the way it generates pseudo-code and basic block 
graphs out of instruction sequences.

--
Paulo