On Tuesday, 27 March 2018 at 21:49:16 UTC, Walter Bright wrote:
> On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
>> - ability to write file during CTFE is not necessarily positive. THough I can't tell why from the top of my mind.
>
> The act of compiling a buggy program not influence the global state of the computer. It should not be necessary to vet code downloaded from the internet before even compiling it to ensure it doesn't mess up the system.

The moment there is make or other build tool this is all futile.

>
> CTFE should run in a sandbox. It must be safe to compile code.

I agree but mostly on the grounds of purity and reproducibility. It also enables caching and incremental builds.

Safety - not so much.

On Wednesday, 28 March 2018 at 20:50:51 UTC, Dmitry Olshansky wrote:
> On Tuesday, 27 March 2018 at 21:49:16 UTC, Walter Bright wrote:
>> On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
>>> - ability to write file during CTFE is not necessarily positive. THough I can't tell why from the top of my mind.
>>
>> The act of compiling a buggy program not influence the global state of the computer. It should not be necessary to vet code downloaded from the internet before even compiling it to ensure it doesn't mess up the system.
>
> The moment there is make or other build tool this is all futile.
>
>>
>> CTFE should run in a sandbox. It must be safe to compile code.
>
> I agree but mostly on the grounds of purity and reproducibility. It also enables caching and incremental builds.
>
> Safety - not so much.

Indeed, even without such high level tools using the linker is dangerous due to issues that nobody wants to consider vulnerabilities.

For demo:

$ mkdir test ; cd test
$ echo 'import std.stdio; void main(){ writeln("test"); }' > test.d
$ ln -s shouldntexist test
$ dmd test.d
$ ls -l
total 760K
-rw-r--r-- 1 cym13 cym13   90 Mar 29 00:28 test.d
lrwxrwxrwx 1 cym13 cym13   13 Mar 29 00:33 test -> shouldntexist*
-rw-r--r-- 1 cym13 cym13  14K Mar 29 00:33 test.o
-rwxr-xr-x 1 cym13 cym13 740K Mar 29 00:33 shouldntexist*

This can easily lead to privilege escalation by creating sensitive files in specific locations with arbitrary content (~/.ssh/authorized_keys comes to mind).

Ok, this needs a specially crafted symlink, but it's one more thing to check before compiling anything... Compiling just can't reasonably be assumed to be secure (although I'd very much like it to be).

On 3/28/2018 1:27 PM, Jacob Carlborg wrote:
> There's usually nothing that prevents the build tool to write files at build time. Dub can do this.

It's expected with a build tool. Not a compiler.

On 3/28/2018 1:50 PM, Dmitry Olshansky wrote:
> Safety - not so much.

I remember back in the olden dayz when Microsoft was pushing ActiveX controls hard. ActiveX controls were blobs of code automatically downloaded from the internet that were embedded in your spreadsheet, word document, etc.

What could possibly go wrong? :-)

On Wed, Mar 28, 2018 at 04:29:28PM -0700, Walter Bright via Digitalmars-d-announce wrote:
> On 3/28/2018 1:50 PM, Dmitry Olshansky wrote:
> > Safety - not so much.
> 
> I remember back in the olden dayz when Microsoft was pushing ActiveX controls hard. ActiveX controls were blobs of code automatically downloaded from the internet that were embedded in your spreadsheet, word document, etc.
> 
> What could possibly go wrong? :-)

+1.

And today, even after Javascript-delivered Meltdown, people still don't get it. *shrug*


T

-- 
MASM = Mana Ada Sistem, Man!

On Wednesday, 28 March 2018 at 23:29:28 UTC, Walter Bright wrote:
> On 3/28/2018 1:50 PM, Dmitry Olshansky wrote:
>> Safety - not so much.
>
> I remember back in the olden dayz when Microsoft was pushing ActiveX controls hard. ActiveX controls were blobs of code automatically downloaded from the internet that were embedded in your spreadsheet, word document, etc.
>
> What could possibly go wrong? :-)

I remember it... I even used some :)
And it was efficient!

But look at it today - many websites are basically a huge program running in a sandbox. And with more APIs they don’t need a particular page open to run in background and many other limitations are lifted.

Still don’t understand why code signing became required on desktop, but not in the web.

On Wednesday, 28 March 2018 at 23:25:09 UTC, Walter Bright wrote:

> It's expected with a build tool. Not a compiler.

It depends. The compilers are doing more and more work these days. Initially, DMD could not build libraries, now it can. DMD does not output assembly files and runs an assembler to produce object files, some compilers do. Clang can do this but is moving the same direction as DMD: having the complier do it. It think they're looking into having the compiler do the linking as well.

So what's expected is subjective.

--
/Jacob Carlborg

On Wednesday, 28 March 2018 at 23:25:09 UTC, Walter Bright wrote:
> On 3/28/2018 1:27 PM, Jacob Carlborg wrote:
>> There's usually nothing that prevents the build tool to write files at build time. Dub can do this.
>
> It's expected with a build tool. Not a compiler.

With the frame of mind prevalent in our Industry I really want to have compiler includibg codegen as a bunch of library components.

Then there is no problem innovating while people argue over things “allowed” for a compiler, or a linker, or a build tool. None of these actually have to be apps talking via files.

If I look closely every program I see is a graph database, with nodes sometimes being code, types, sometimes data, other meta-data such as ABI attributes or conditional compilation flags, documentation, external tools, specs and databases are also part of this. Code that produces code is also part of such graph, and CTFE/macroses would just be finer grained approach.

Why process graphs piece-wise in a frentic dance of command-line tools that try to fit all to a tree of files (multiple ones, in many location, and part in some CMS) and then have editors/IDEs integrate? Was easier I believe + inertia, easy != simple though.

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:
> D and nim are both very promising.
> I created this git repo to compare them:
>
> https://github.com/timotheecour/D_vs_nim/
>
> Goal: up to date and objective comparison of features between D and nim (to help deciding what language to use), and 1:1 map of features and libraries to help D users learn nim and vice versa.
>
> PRs are welcome and merged fast

My only question would be if you think what is currently posted is objective.

On 2018-03-30 08:53, Dmitry Olshansky wrote:

> With the frame of mind prevalent in our Industry I really want to have compiler includibg codegen as a bunch of library components.
> 
> Then there is no problem innovating while people argue over things “allowed” for a compiler, or a linker, or a build tool. None of these actually have to be apps talking via files.
> 
> If I look closely every program I see is a graph database, with nodes sometimes being code, types, sometimes data, other meta-data such as ABI attributes or conditional compilation flags, documentation, external tools, specs and databases are also part of this. Code that produces code is also part of such graph, and CTFE/macroses would just be finer grained approach.
> 
> Why process graphs piece-wise in a frentic dance of command-line tools that try to fit all to a tree of files (multiple ones, in many location, and part in some CMS) and then have editors/IDEs integrate? Was easier I believe + inertia, easy != simple though.

I completely agree. I was quite surprised when I started to use libclang and the only way to pass options to the library (which are usually command line flags) was to pass it as an array of command line options. This is the C API, the C++ API is more advanced.

-- 
/Jacob Carlborg