import std.stdio;
string foo()() {
return `void main() { writefln("hello world"); }`;
}
mixin(foo);
Compiled with -O -release
Copy from IDA PRO strings window:
.CRT$XIA:0043F100 00000029 C void main() { writefln(\"hello world\"); }
Comment #1 by andrej.mitrovich — 2013-08-16T15:40:45Z
W.r.t. -O and -release, if this feature is implemented I think it would be better if it was a separate switch (e.g. -security), rather than have to depend on security features based on what optimization some compiler implements. Sometimes you can't even compile with -release or -O (due to bugs), so you shouldn't be forced to lose security features because of optimization bugs. (+ maybe D could standardize on these security features).
Comment #2 by temtaime — 2013-08-17T04:21:59Z
I think there is no need to have any switches.
If D debugger requires mixin's source - then source in binary should to be only when -g flag specified.
Comment #3 by clugdbug — 2013-08-19T05:01:21Z
The mixin source isn't put into the binary. What you're seeing is the executable code of the template that you instantiated. It's exactly as if you wrote:
string foo() {
return `void main() { writefln("hello world"); }`;
}
There's a possible optimisation: templates instantiated only in a compile-time context don't need to be put into the binary. Unfortunately the linker isn't smart enough to detect they are never used. This should be fixable, but it's not actually a bug.
Comment #4 by dlang-bugzilla — 2013-08-19T05:05:42Z
> This should be fixable, but it's not actually a bug.
FWIW, it can be a serious issue for closed-source software products, where details about the source code must not be present in executables.
Comment #5 by andrej.mitrovich — 2013-08-19T06:45:42Z
(In reply to comment #4)
> > This should be fixable, but it's not actually a bug.
>
> FWIW, it can be a serious issue for closed-source software products, where
> details about the source code must not be present in executables.
Yeah. This is why I propose a -security switch to add guarantees about what the compiler does, rather than rely on compiler optimizations.
Comment #6 by hsteoh — 2013-08-19T12:58:15Z
IMO DMD should somehow keep track of which template instantiations actually require code to be emitted. If a template function only runs in CTFE but not at runtime, that code shouldn't even be emitted in the first place.
Tho I understand that separate compilation may make this tricky. :)
One possible approach is to emit all template instantiations in a separate static library that the linker can then selectively pull from. Linkers are designed to only pull parts of the library that are actually referenced, so this won't require massive compiler changes. Then we can both reduce template bloat and avoid security issues like this one.
Comment #7 by github-bugzilla — 2013-11-25T04:12:48Z
Bump.
Please, fix it and improve linker's efficiency.
There is currently too many strings in resulting binary that not referenced, it also increasing binary size.
I'm developing closed source project and it's critical for me.
Comment #9 by robert.schadek — 2024-12-13T18:10:24Z