4 ms·

Recently, ( https://news.ycombinator.com/item?id=23055121 https://news.ycombinator.com/item?id=23055121 ), Walter Bright pointed out that although D has extensi

Recently, ( https://news.ycombinator.com/item?id=23055121 https://news.ycombinator.com/item?id=23055121 ), Walter Bright pointed out that although D has extensive compile-time meta programming support, system (and, I imagine, arbitrary dll) calls are explicitly not allowed because of security concerns. If I understand the Circle docs correctly... [...] searched for in the pre-loaded standard binaries: libc, libm, libpthread, libstdc++ and libc++abi. Additional libraries may be loaded with the -M compiler switch. When the requested function is found, a foreign-function call is made, [...] ...all libraries are fair game? And I guess you might be able to do your own function/dll probing with libdl. Do you guys see this as a feature or a liability?

Reelin 6y ago
I love the D language but I actually think its designers got that point wrong. Compilers are _far_ from security hardened and an attacker slipping something evil into the output binary is probably equally as bad anyway (you distribute it to your users after all). Ultimately you shouldn't be compiling code you don't trust without a good reason and appropriate precautions. As a counterexample, as far as I'm aware Common Lisp makes no distinction between execution that occurs at compile time versus run time. It still seems to be doing pretty well though!
- rurban 6y ago
  Common Lisp programmers know what they do. We do have the same problem in perl, where people don't get the difference of a BEGIN block to an INIT block. With C++ the template syntax is so horrible convoluted, that I doubt people get the idea of compile-time expressions. What is allowed, and what forbidden.
- guenthert 6y ago
  > Common Lisp makes no distinction between execution that occurs at compile time versus run time. That's not quite phrased correctly. Common Lisp very well makes such a distinction, but allows code to be executed at compile time, load time or run time. See http://www.lispworks.com/documentation/HyperSpec/Body/s_eval_w.htm#eval-when http://www.lispworks.com/documentation/HyperSpec/Body/s_eval... for detaills.
rurban 6y ago
The problem with compile-time expressions are side-effects. They are only done locally, which is sometimes not what you want. syscalls, fileio, Config checks are not done at runtime, and this is for 99% a bug. You really need to know what you do. And each such sideffect is only done once, when you run the compiler. Not at the client.

Reelin 6y ago

I love the D language but I actually think its designers got that point wrong. Compilers are _far_ from security hardened and an attacker slipping something evil into the output binary is probably equally as bad anyway (you distribute it to your users after all). Ultimately you shouldn't be compiling code you don't trust without a good reason and appropriate precautions. As a counterexample, as far as I'm aware Common Lisp makes no distinction between execution that occurs at compile time versus run time. It still seems to be doing pretty well though!

rurban 6y ago
Common Lisp programmers know what they do. We do have the same problem in perl, where people don't get the difference of a BEGIN block to an INIT block. With C++ the template syntax is so horrible convoluted, that I doubt people get the idea of compile-time expressions. What is allowed, and what forbidden.
guenthert 6y ago
> Common Lisp makes no distinction between execution that occurs at compile time versus run time. That's not quite phrased correctly. Common Lisp very well makes such a distinction, but allows code to be executed at compile time, load time or run time. See http://www.lispworks.com/documentation/HyperSpec/Body/s_eval_w.htm#eval-when http://www.lispworks.com/documentation/HyperSpec/Body/s_eval... for detaills.

rurban 6y ago

The problem with compile-time expressions are side-effects. They are only done locally, which is sometimes not what you want. syscalls, fileio, Config checks are not done at runtime, and this is for 99% a bug. You really need to know what you do. And each such sideffect is only done once, when you run the compiler. Not at the client.