CTFE and DI: The Crossroads of D

H. S. Teoh hsteoh at quickfur.ath.cx
Wed May 9 15:43:57 PDT 2012


On Wed, May 09, 2012 at 06:17:41PM -0400, Nick Sabalausky wrote:
> My take, FWIW:
> 
> 1. DI is only useful for those anachronistic corporations who beleive
> in code-hiding (and even then, only the ones who release libs), which
> regardless of everything else, isn't even *realistic* anyway - there's
> always reverse-engineering, and with the super-popular JS there *IS
> NO* pre-compiled form, and yet non-OSS companies *still* get by just
> fine anyway. If you're relying on the increasingly-irrelevent practice
> of code-hiding (which there is *no such thing* - only obfuscation,
> which is exactly what compiling does, it only obfuscates the source,
> it doesn't hide it), then you need to accept that there *are* going to
> be things you will *never* be able to do, period, like virtual
> templates (which *are* possible in theory if all the source is
> available, even if D doesn't currently allow it).

This is why I kept proposing that .di's should have zero implementation.
ZERO. No function bodies, no template bodies, NOTHING except API
information. All of the implementation stuff should be compiled into
some intermediate form and stuck into special sections in the object
file that the compiler understands. For example, it can be a serialized
AST of the corresponding source. When you import the module, the
compiler automatically looks up the corresponding section in the
precompiled library and gets whatever info it needs (template bodies,
CTFE function bodies, whatever).

Yes such a thing can be reverse-engineered, but that is no different
from distributing your binary in the first place (someone determined
enough to steal your code will be able to reverse-engineer even the most
sophisticated obfuscations you apply to your code -- if the CPU can run
the code, it can be reverse-engineered). It really is just a matter of
deterring the casual shoulder-peekers from peeking at your "precious"
code. Code in the form of ASTs stored in the compiled library should be
deterrent enough -- anyone that actually bothers to reverse engineer
that is determined enough that you will not be able to stop him no
matter what you do anyway.


> 2. We should be seriously looking into the idea of making CTFE work by
> executing already-compiled code, a la Nemerle (but without needing the
> extra build step). There may be enough technical hurdles involved to
> hold this back for [the still-hypothtical] D3, but it should at least
> be a direction we should be seriously considering. (Unless someone can
> already come up with a deal-breaking reason now.) Actually, there's
> *FAR* more important things than this right now, like a solid
> ARM-tablet toolchain, so this should definitely just be an "on hold
> for now" feature.
[...]

+1. You do have the problem of what to do in a cross-compiler, though.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft
system vulnerabilities cannot touch Linux---is priceless. -- Frustrated
system administrator.


More information about the Digitalmars-d mailing list