On Tuesday, 7 June 2016 at 02:04:41 UTC, Mithun Hunsur wrote:
On Monday, 6 June 2016 at 21:57:20 UTC, Pie? wrote:
On Monday, 6 June 2016 at 21:31:32 UTC, Alex Parrill wrote:
[...]
This doesn't seem to be the case. In a release build, even
though I never "use" the string, it is embedded. I guess this
is due to not using enum but enum seems to be much harder to
work with if not impossible.
[...]
Not necessarily, You chased that rabbit quite far! The data
your reading could contain sensitive information only used at
compile time and not meant to embed. For example, the file
could contain login and password to an SQL database that you
then connect, at compile time and retrieve that information
the disregard the password(it is not needed at run time).
This is definitely possible, but it can depend on your
compiler. If you use an enum, it'll be treated as a
compile-time constant - so if you never store it anywhere (i.e.
enum File = import('file.txt'); string file = File; is a no-no
at global scope), you should be fine.
If you do find yourself in the precarious situation of storing
the data, then it's up to your compiler to detect that there
are no runtime references to the data and elide it. LDC and GDC
most likely do this, but I doubt DMD would.
For safety, you should try and reformulate your code in terms
of enums and local variables; this *should* work with DMD, but
it's possible it's not smart enough to catch onto the fact that
the function is never used at run-time (and therefore does not
need to be included in the executable).
Ok, I will assume it will be able to be removed for release. It
is an easy check(just search if binary contains file info). I'm
sure an easy fix could be to write 0's over the data in the
binary if necessary.
If I use an enum dmd does *not* remove it in release build. I
will work on parsing the file using CTFE and hopefully dmd will
not try to keep it around, or it can be solved using gdc/ldc or
some other method.
