5 ms·

Jonathan Blow’s programming language allows almost anything to execute during compilation as well. It’s neat. Here’s an old video where he demonstrated this: ht

• WalterBright 5y ago
  That's true. His implementation also allows compile time function execution to make system calls. D disallows that in order to prevent malicious source code from being distributed and tricking people into compiling it. There is a mechanism to sent output to stdout, input can be read from a file residing on the compiler's system, and that's it. It's also why CTFE doesn't allow pointer monkey business, like coercing an integer into a pointer and dereferencing it.
  • SubjectToChange 5y ago
    If you're compiling malicious code, haven't you already lost? I don't see how preventing pointer manipulation at compile time (or anything else, really) improves security unless people never run the executable they compiled.
    • WalterBright 5y ago
      People expect to check source code before running it. They do not expect to have to check it before compiling it. Malware works by taking advantage of peoples' expectations.
      • SubjectToChange 5y ago
        People expect to check source code before running it. They do not expect to have to check it before compiling it. Why are they compiling untrusted code? To see if it's syntactically correct? If the code you're compiling is using a build system, you're already compromised. Compilation of untrusted code should always be sandboxed, regardless of compile-time programming capabilities.
      • gpderetta 5y ago
        Given the way modern IDEs work, unrestricted compile time evaluation would make it dangerous to even open potentially malicious code.
    • lalaithion 5y ago
      It means that you need to do $ sandbox "foobarc malicious.foobar -o executable && ./executable" instead of $ foobarc malicious.foobar -o executable $ sandbox ./executable Which isn't totally intuitive.
      • WalterBright 5y ago
        Yes, I don't really want to have to recommend to people that they have to run the compiler in a sandbox.
      • SubjectToChange 5y ago
        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
    • junon 5y ago
      Do you audit every repository you clone and build?
  • rurban 5y ago
    In Perl we only discourage IO at compile-time, because this only runs at the build system, not the client. And IO is mostly side effects only, and not restorable. Everything else is free. In perl this is simpler done, everything inside BEGIN{} blocks.