Hacker News Reader

Comment by WalterBright | Hacker News Reader

> we could imagine a future version of C++ where this [constexpr annotation] isn’t required: if we’re calling a function at compile-time, the compiler tries to execute it at compile-time. If it works, good, otherwise, it issues a diagnostic.

This is how D's CTFE (Compile Time Function Execution) works. You can execute at compile time any function, and it will work as long as the source code is available to the compiler, and it doesn't access globals or do pointer monkey business.

You can indeed build a program that runs completely at compiler time. Here's a compile time ray tracer in D circa 2006:

http://h3.gd/posts/ctrace/

View on HN

Virgil initializers are run at compile time and can literally run any code in the program to build up any data structures you want. The result of initialization is the transitive closure of objects reachable from the globals. The compiler goes further and optimizes your code against the initialized heap, devirtualizing, inlining, and constant-folding, throwing away dead code, dead fields, and dead objects. That's great for microcontrollers because you can just allocate your entire heap at compile time and then bake it into your image.

I wrote a paper about it in 2006: https://escholarship.org/uc/item/13r0q4fc

I still work (primarily, in fact) on Virgil. It's great not having any distinction between compile-time initialization and runtime.

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: https://youtu.be/UTqZNujQOlA

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.

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.

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.

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.

Given the way modern IDEs work, unrestricted compile time evaluation would make it dangerous to even open potentially malicious code.

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.

Yes, I don't really want to have to recommend to people that they have to run the compiler in a sandbox.

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.

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++.

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.

Testing code requires executing it. This is true for compile-time code or run-time code.

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/a5b16bd8e72a447d509cca862e...

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.

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.

> 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.

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.

Do you audit every repository you clone and build?

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.

And Circle, which is a C++ compiler with an added annotation,@meta.

https://www.circle-lang.org

There are some issues with it, because many ISO members want compile time capabilities constrained by constexpr, instead of the complete language, like Circle compiler allows.

I don't see the value TBH. constexpr is excellent for code readability. Even if the compiler could figure it out I'd vote to keep it. That said, if compiler could figure it out than you can probably set up your editor to annotate it.

As the article points out, an entire function doesn't need to be CTFE compatible, only the particular path taken through the function by the interpreter.

This makes constexpr more of an impediment than an enabler.

Besides, people soon discover the utility of using functions at both compile and run time, and nobody has ever asked for D to require an annotation for it in 15 years.

I don't see how constexpr is helpful for readability. As it stands, constexpr adds a significant amount of syntactic noise. D's approach is the correct one, IMO.

Check Circle for what would be possible in C++, if the compiler would do it for you.

https://www.circle-lang.org/

Reply on news.ycombinator.com