On Saturday, 13 July 2013 at 07:13:37 UTC, Walter Bright wrote:
> On 7/12/2013 11:52 PM, BLM768 wrote:
>> On Saturday, 13 July 2013 at 04:23:56 UTC, Walter Bright wrote:
>>>
>>> A big problem with it would be the equivalent of the "SQL Injection Exploit".
>>> Since the compiler can now execute arbitrary code, someone passing around
>>> malicious source code could do anything to your system.
>>
>> Assuming that the user is compiling the code in order to run it (which does seem
>> to be the most common case, at least in my experience), the user is already
>> running arbitrary code. I don't really see how this would create a greater
>> security risk than what already exists.
>
> People can be endlessly creative at this kind of thing. I'm not at all sure you and I have thought of every possible exploit.

Any idea how difficult such a thing would be to implement? Any one willing to work on something like this? If something like this was made, would it be included?

On Friday, 12 July 2013 at 23:34:05 UTC, Timothee Cour wrote:
> regarding added complexity: the only thing this adds is 1 function (calling
> an executable, with option to redirect stdin/out/err). And yes, that could
> read mail as you joked if the user called such a program inside his D
> function, but that would require ZERO change in compiler, apart from that
> ONE function to support calling external programs.

It's one function now. Like CTFE, it won't be long before everyone is using it and we see its limitations, or we see more opportunities for further enhancement.


> we need this for the same reason we need CTFE: try using makefiles to
> achieve what CTFE does. Using a separate build is way less convenient and
> doesn't allow complex interactions, as it requires the process to be
> sequential: do other stuff THEN compile with dmd. Whereas integrating it
> inside compilation would allow interdependent computations offloaded to an
> external process.

Let's be clear here: we don't "need" this we "want" this.

There's an endless number of features we want, but we have to draw the line somewhere. This is classic feature creep. As Andrei said at DConf, we need to be more professional in the development of D. Endlessly adding features is not a professional approach to software development.

In my opinion, the only features that should be added at this point are to fix language problems. For example, some form of copy constructors will be necessary to fix the const postblit problem. Adding features for convenience should be postponed for D3, or at the very least postponed until all major language issues are resolved.

On Friday, 12 July 2013 at 22:46:39 UTC, Justin Whear wrote:
> On Sat, 13 Jul 2013 00:36:21 +0200, Peter Alexander wrote:
>
>> On Friday, 12 July 2013 at 20:42:50 UTC, Tofu Ninja wrote:
>>> So I had an idea recently, wouldn't it be cool to have the ability to
>>> call an executable at compile time and capture its output.
>> 
>> How long until D compilers are able to read mail? :-)
>> 
>> There's many obvious applications of this proposed feature, but I say
>> such things should be delegated to the build process. Just run those
>> executables using a makefile, or whatever build system you use.
>> 
>> If you need compile time inputs from your D code then just run a
>> separate build to extract them. Yes it's more work and less convenient,
>> but I think we need to be careful with how much is added to the D
>> compilers. We don't want to turn them into operating systems.
>
> Other compilers allow symbols/macros to be defined on the command line,
> e.g. gcc's `-D` flag;  it'd be nice for DMD to define a similar mechanism
> for defining enums, e.g.
>
> ---D code---
>   void main() { writeln(VERSION_NUMBER); }
> ------------
>
> dmd main.d -DVERSION_NUMBER=1.2
>
> Currently I have to use my makefiles to output a whole file which defines
> the various build constants.

A few minutes ago, I have a same issue. I need add some enum values as a compile option.

Now I have something like this:
version (Parser) {
	enum Application = "parser";
}
version (Report) {
	enum Application = "report";
}

But would be nice to have posibility to add same value as a compile parametr, so I could have code like this:

enum Application = __traits(getParametrValue, "MY_APPLICATION_NAME");

and compile code with some args for eg.: -VMY_APPLICATION_NAME=parser

On Saturday, 13 July 2013 at 11:19:49 UTC, Daniel Kozak wrote:
> A few minutes ago, I have a same issue. I need add some enum values as a compile option.
>
> Now I have something like this:
> version (Parser) {
> 	enum Application = "parser";
> }
> version (Report) {
> 	enum Application = "report";
> }
>
> But would be nice to have posibility to add same value as a compile parametr, so I could have code like this:
>
> enum Application = __traits(getParametrValue, "MY_APPLICATION_NAME");
>
> and compile code with some args for eg.: -VMY_APPLICATION_NAME=parser

You can solve this using import expressions.

---parser/config.include---
enum Application = "parser";

---report/config.include---
enum Application = "report";

---main.d---
mixin(import("config.include"));

---Makefile---
parser:
    dmd main.d -Jparser

report:
    dmd main.d -Jreport

W dniu 13.07.2013 09:13, Walter Bright pisze:
> On 7/12/2013 11:52 PM, BLM768 wrote:
>> On Saturday, 13 July 2013 at 04:23:56 UTC, Walter Bright wrote:
>>>
>>> A big problem with it would be the equivalent of the "SQL Injection
>>> Exploit".
>>> Since the compiler can now execute arbitrary code, someone passing
>>> around
>>> malicious source code could do anything to your system.
>>
>> Assuming that the user is compiling the code in order to run it (which
>> does seem
>> to be the most common case, at least in my experience), the user is
>> already
>> running arbitrary code. I don't really see how this would create a
>> greater
>> security risk than what already exists.
>
> People can be endlessly creative at this kind of thing. I'm not at all
> sure you and I have thought of every possible exploit.

Use sandboxing. On Linux it's easy: http://en.wikipedia.org/wiki/Seccomp. But, it could be difficult to create cross-platform solution.

On 7/12/13 5:42 PM, Tofu Ninja wrote:
> So I had an idea recently, wouldn't it be cool to have the ability to
> call an executable at compile time and capture its output. Something
> like the string imports but instead of opening and reading a text file,
> it run an executable, waits for it to finish, and grabs its output.
>
> It would get really cool if you could pass this executable some args and
> then mix in its out put into your own code. It could be used similarly
> to how CTFE are used but with out the overhead of trying to compile that
> function and what not and with out the limitations on what it can do.
>
> I could imagine all sorts of things that would be possible with this
> that is currently not.
>
> Not sure if this is something that could be implemented easily, but
> seems like something that could be done and something that would be
> really cool.

What would actually be cool is to run any kind of code at compile time (within a sandbox, if you want). For example reading a mysql database and generating classes for the tables at compile time. No need to run a separate executable and remember to run it before compiling your program.

But this has been discussed many times in this list, and it won't happen, because compile time functions are not jitted and run, they are just interpreted.

You ask for executing a program at compile time. Somebody will ask reading a file at compile time. Another one will ask reading a schema from a database. Yet another will want to do a web scraper at compile time to generate efficient code from that (not sure that's useful :-P)

On 7/13/2013 1:34 AM, Tofu Ninja wrote:
> Any idea how difficult such a thing would be to implement? Any one willing to
> work on something like this? If something like this was made, would it be included?

It would be easy to implement. I don't know if it should be included or not, though.

On Saturday, 13 July 2013 at 11:25:05 UTC, Peter Alexander wrote:
> On Saturday, 13 July 2013 at 11:19:49 UTC, Daniel Kozak wrote:
>> A few minutes ago, I have a same issue. I need add some enum values as a compile option.
>>
>> Now I have something like this:
>> version (Parser) {
>> 	enum Application = "parser";
>> }
>> version (Report) {
>> 	enum Application = "report";
>> }
>>
>> But would be nice to have posibility to add same value as a compile parametr, so I could have code like this:
>>
>> enum Application = __traits(getParametrValue, "MY_APPLICATION_NAME");
>>
>> and compile code with some args for eg.: -VMY_APPLICATION_NAME=parser
>
> You can solve this using import expressions.
>
> ---parser/config.include---
> enum Application = "parser";
>
> ---report/config.include---
> enum Application = "report";
>
> ---main.d---
> mixin(import("config.include"));
>
> ---Makefile---
> parser:
>     dmd main.d -Jparser
>
> report:
>     dmd main.d -Jreport
Thanks, this is usefull :)

On Fri, Jul 12, 2013 at 9:23 PM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 7/12/2013 5:00 PM, Timothee Cour wrote:
>
>> Let's put it another way: if I or someone else made a pull request for
>> CTFE
>> "exec", would it have a chance of being accepted?
>>
>
> A big problem with it would be the equivalent of the "SQL Injection Exploit". Since the compiler can now execute arbitrary code, someone passing around malicious source code could do anything to your system.
>
>
Which is why I suggested in my first post above that it should be enabled
by a compiler switch (eg: dmd -enable_exec) for safety reasons (just as
string import requires -J).
At the very least it is useful for debugging personal projects.

On Sat, Jul 13, 2013 at 9:05 AM, Ary Borenszweig <ary@esperanto.org.ar>wrote:

> On 7/12/13 5:42 PM, Tofu Ninja wrote:
>
>> So I had an idea recently, wouldn't it be cool to have the ability to call an executable at compile time and capture its output. Something like the string imports but instead of opening and reading a text file, it run an executable, waits for it to finish, and grabs its output.
>>
>> It would get really cool if you could pass this executable some args and then mix in its out put into your own code. It could be used similarly to how CTFE are used but with out the overhead of trying to compile that function and what not and with out the limitations on what it can do.
>>
>> I could imagine all sorts of things that would be possible with this that is currently not.
>>
>> Not sure if this is something that could be implemented easily, but seems like something that could be done and something that would be really cool.
>>
>
> What would actually be cool is to run any kind of code at compile time (within a sandbox, if you want). For example reading a mysql database and generating classes for the tables at compile time. No need to run a separate executable and remember to run it before compiling your program.
>
> But this has been discussed many times in this list, and it won't happen, because compile time functions are not jitted and run, they are just interpreted.
>
> You ask for executing a program at compile time. Somebody will ask reading a file at compile time. Another one will ask reading a schema from a database. Yet another will want to do a web scraper at compile time to generate efficient code from that (not sure that's useful :-P)
>

reading a file at compile time is already possible with string import.