4 ms·

And what if you are compiling more than a single file? What if the project or library you are compiling uses make/cmake/gn/etc? The point is that restrictions

And what if you are compiling more than a single file? What if the project or library you are compiling uses make/cmake/gn/etc? The point is that restrictions on compile-time programming only protect you in trivial cases. And I can't think of many reasons to fully compile code without the intent of running the executable.

usefulcat 5y ago
Testing. If you wanted to test that your compile-time code is correct, I'd imagine the typical--if not only--way to do that would be to compile it. Certainly that's true for constexpr in c++.
- johannes1234321 5y ago
  you could compile it to verify, but you usally compile it using a build system to set include paths right etc. that build system could include a `rm -rf $HOME 2>/dev/null` or similar already.
- SubjectToChange 5y ago
  Testing code requires executing it. This is true for compile-time code or run-time code.
  - WalterBright 5y ago
    Quite a lot of the tests in the D compiler suite are compile time only. It makes for running the test suite much faster. To test ImportC, which inherits D's ability to execute functions at compile time, I've been using a lot of _Static_assert() constructs. https://github.com/dlang/dmd/blob/a5b16bd8e72a447d509cca862e2ac8ad3353ee43/test/compilable/testcstuff1.c#L131 https://github.com/dlang/dmd/blob/a5b16bd8e72a447d509cca862e...
WalterBright 5y ago
If you want a compiler that is designed to enable ransomware injection into your system merely by compiling a file, that's fine with me. But it won't be D.
- SubjectToChange 5y ago
  I don't expect D to change the way it does things. But I think your security concerns lack merit. It doesn't make sense to produce an executable, not execute it, then go audit the code. Just audit the code in the first place. And like I mentioned earlier, virtually no project is purely static code. They include shell scripts, make files, and tons of other things. Working with untrusted code is dangerous, period. Making compile-time programming a little safer is just passing the buck.
  - WalterBright 5y ago
    > It doesn't make sense to produce an executable, not execute it, then go audit the code. If you're auditing the code by examining it with an IDE, it could certainly get compiled.
    - SubjectToChange 5y ago
      Many IDEs automatically start the produced executable too. Again, I don't understand why you'd want to wait until you have an unwanted/untrusted executable to begin auditing code.

usefulcat 5y ago

Testing. If you wanted to test that your compile-time code is correct, I'd imagine the typical--if not only--way to do that would be to compile it. Certainly that's true for constexpr in c++.

johannes1234321 5y ago
you could compile it to verify, but you usally compile it using a build system to set include paths right etc. that build system could include a `rm -rf $HOME 2>/dev/null` or similar already.
SubjectToChange 5y ago
Testing code requires executing it. This is true for compile-time code or run-time code.
- WalterBright 5y ago
  Quite a lot of the tests in the D compiler suite are compile time only. It makes for running the test suite much faster. To test ImportC, which inherits D's ability to execute functions at compile time, I've been using a lot of _Static_assert() constructs. https://github.com/dlang/dmd/blob/a5b16bd8e72a447d509cca862e2ac8ad3353ee43/test/compilable/testcstuff1.c#L131 https://github.com/dlang/dmd/blob/a5b16bd8e72a447d509cca862e...

WalterBright 5y ago

If you want a compiler that is designed to enable ransomware injection into your system merely by compiling a file, that's fine with me. But it won't be D.

SubjectToChange 5y ago
I don't expect D to change the way it does things. But I think your security concerns lack merit. It doesn't make sense to produce an executable, not execute it, then go audit the code. Just audit the code in the first place. And like I mentioned earlier, virtually no project is purely static code. They include shell scripts, make files, and tons of other things. Working with untrusted code is dangerous, period. Making compile-time programming a little safer is just passing the buck.
- WalterBright 5y ago
  > It doesn't make sense to produce an executable, not execute it, then go audit the code. If you're auditing the code by examining it with an IDE, it could certainly get compiled.
  - SubjectToChange 5y ago
    Many IDEs automatically start the produced executable too. Again, I don't understand why you'd want to wait until you have an unwanted/untrusted executable to begin auditing code.