On Friday, 5 January 2024 at 19:21:36 UTC, H. S. Teoh wrote:
> ...
> DIP1036 is already merged and working. E.g., the following works today:
> ...

Already!? - I need to check this but I couldn't find any nightly build (The currently Readme points to original Dlang), so I think I will need to build myself?

Matheus.

On Saturday, 6 January 2024 at 13:18:40 UTC, Bastiaan Veelo wrote:
> ...

With the risk of putting myself in hot waters, my understanding (I may be wrong!) is that after the xmas incident, Adam posts were under moderation and he went lay low mode around this mailing list.

So I'd suggest you to talk to Adam directly over IRC #opend which I think it will reach him fast.

Matheus.

On Sat, Jan 06, 2024 at 01:53:18PM +0000, matheus via Digitalmars-d wrote:
> On Friday, 5 January 2024 at 19:21:36 UTC, H. S. Teoh wrote:
> > ...
> > DIP1036 is already merged and working. E.g., the following works today:
> > ...
> 
> Already!? - I need to check this but I couldn't find any nightly build (The currently Readme points to original Dlang), so I think I will need to build myself?
[...]

Thanks to the recent unified Makefile (which happened before the fork), you can just git clone dmd and phobos (under the same parent directory) and run Make in each, and you should get a working compiler.


T

-- 
Change is inevitable, except from a vending machine.

On Saturday, 6 January 2024 at 13:53:18 UTC, matheus wrote:
>
> Already!? - I need to check this but I couldn't find any nightly build (The currently Readme points to original Dlang), so I think I will need to build myself?

Yes, the fork was announced just a few days ago and the CI system has not yet been built up.

On Saturday, 6 January 2024 at 14:44:07 UTC, H. S. Teoh wrote:
> On Sat, Jan 06, 2024 at 01:53:18PM +0000, matheus via Digitalmars-d wrote:
>> On Friday, 5 January 2024 at 19:21:36 UTC, H. S. Teoh wrote:
>> > ...
>> > DIP1036 is already merged and working. E.g., the following works today:
>> > ...
>> 
>> Already!? - I need to check this but I couldn't find any nightly build (The currently Readme points to original Dlang), so I think I will need to build myself?
> [...]
>
> Thanks to the recent unified Makefile (which happened before the fork), you can just git clone dmd and phobos (under the same parent directory) and run Make in each, and you should get a working compiler.
>
>
> T

except for apple silicon :-)

On Saturday, 6 January 2024 at 14:39:44 UTC, matheus wrote:
> On Saturday, 6 January 2024 at 13:18:40 UTC, Bastiaan Veelo wrote:
>> ...
>
> With the risk of putting myself in hot waters, my understanding (I may be wrong!) is that after the xmas incident, Adam posts were under moderation and he went lay low mode around this mailing list.
>
> So I'd suggest you to talk to Adam directly over IRC #opend which I think it will reach him fast.
>
> Matheus.

What happened on Christmas?

On Sat, Jan 06, 2024 at 01:53:18PM +0000, matheus via Digitalmars-d wrote:
> On Friday, 5 January 2024 at 19:21:36 UTC, H. S. Teoh wrote:
> > ...
> > DIP1036 is already merged and working. E.g., the following works today:
> > ...
> 
> Already!? - I need to check this but I couldn't find any nightly build (The currently Readme points to original Dlang), so I think I will need to build myself?
[...]

Thought I'd showcase what the string interpolation tuple DIP can do, which currently compiles with the forked compiler and behaves as advertised:

````
// Taken from Adam's interpolation-examples repo
// (https://github.com/adamdruppe/interpolation-examples)
module demo.sql;

import arsd.sqlite;
import lib.sql;

import std.stdio;

void main() {
	auto db = new Sqlite(":memory:");
	db.query("CREATE TABLE sample (id INTEGER, name TEXT)");

	// you might think this is sql injection... but it isn't! the lib
	// uses the rich metadata provided by the interpolated sequence to
	// use prepared statements appropriate for the db engine under the hood
	int id = 1;
	string name = "' DROP TABLE', '";
	db.execi(i"INSERT INTO sample VALUES ($(id), $(name))");

	foreach(row; db.query("SELECT * from sample"))
		writeln(row[0], ": ", row[1]);
}
````

This compiles with the forked compiler today, and correctly handles the dangerous string `name` that imitates a SQL injection attack. Thanks to the compile-time information provided by the interpolation tuple, the backend code is able to understand that the contents of `name` is string data to be bound to a SQL placeholder rather than copied verbatim into a SQL query string (which would have allowed the SQL injection attack to work), so it is able to safely store the data as a harmless string inside the database.

Output (note that the string "' DROP TABLE', '" is stored as a string, and the attempted SQL injection did not work):

----------------
1: ' DROP TABLE', '
----------------

Noteworthy is the fact that the competing string interpolation proposals are *not* immune to this sort of SQL injection attack, because premature conversion of the i"" literal to string *would* result in a successful injection.

My personal hope is that the string interpolation tuple DIP would go through in the official version of D and we would all benefit from it, rather than have the current stalemate continue for another who knows how many years.


T

-- 
Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn

On 1/6/2024 9:35 PM, H. S. Teoh wrote:
> Noteworthy is the fact that the competing string interpolation proposals
> are *not* immune to this sort of SQL injection attack, because premature
> conversion of the i"" literal to string *would* result in a successful
> injection.

The same technique of having a template take the generated tuple and modifying it as it sees fit works with DIP1027, too. I posted an example here in the last debate about this.

The tuple generated from the istring is passed to a template that accepts tuples. The format string is the first element in the tuples, and it is a string literal. The template reads the format string character by character, generating a new format string as it goes. It examines the format specifications, and the type of the corresponding tuple argument, and adjusts the output to the new format string as required.

The template then returns the new tuple which consists of the new format string followed by the arguments.

It's true that in order for this to work,

```
db.execi(i"INSERT INTO sample VALUES ($(id), $(name))");
```
would need to be written as:
```
db.execi(xxx!(i"INSERT INTO sample VALUES ($(id), $(name))"));
```
where `xxx` is the thoroughly unimaginative name of the transformer template.

Is adding the template call an undue burden? Follow the call to deb.execi() with:

```
std.stdio.writeln(i"id = ($(id), name = $(name)");
```
I haven't tried this myself, as I don't have sql on my machine, but I expect the output to stdout would not be what one would expect. I.e. The imported Interpolation functions will produce what is right for sql, not writeln, which would be in error.

Since you do have this setup, please give this line a try and let us know what it prints.

On Sunday, 7 January 2024 at 09:04:16 UTC, Walter Bright wrote:
> On 1/6/2024 9:35 PM, H. S. Teoh wrote:
>> Noteworthy is the fact that the competing string interpolation proposals
>> are *not* immune to this sort of SQL injection attack, because premature
>> conversion of the i"" literal to string *would* result in a successful
>> injection.
>
> The same technique of having a template take the generated tuple and modifying it as it sees fit works with DIP1027, too. I posted an example here in the last debate about this.
>
> The tuple generated from the istring is passed to a template that accepts tuples. The format string is the first element in the tuples, and it is a string literal. The template reads the format string character by character, generating a new format string as it goes. It examines the format specifications, and the type of the corresponding tuple argument, and adjusts the output to the new format string as required.
>
> The template then returns the new tuple which consists of the new format string followed by the arguments.
>
> It's true that in order for this to work,
>
> ```
> db.execi(i"INSERT INTO sample VALUES ($(id), $(name))");
> ```
> would need to be written as:
> ```
> db.execi(xxx!(i"INSERT INTO sample VALUES ($(id), $(name))"));
> ```
> where `xxx` is the thoroughly unimaginative name of the transformer template.
>
> Is adding the template call an undue burden? Follow the call to deb.execi() with:
>
> ```
> std.stdio.writeln(i"id = ($(id), name = $(name)");
> ```
> I haven't tried this myself, as I don't have sql on my machine, but I expect the output to stdout would not be what one would expect. I.e. The imported Interpolation functions will produce what is right for sql, not writeln, which would be in error.
>
> Since you do have this setup, please give this line a try and let us know what it prints.

In our codebase, we are binding of local variables to sql parameters with something like:

  mixin( BindParameters!actualQuery );

Also that way of doing it is not 'an undue burden'.

The whole point is, well, let's move on and simplify it!

DIP1036 could allow us to do that, with better library code and more encapsulation, your proposal simply can't do that without what you call 'more burden'.

Long story short: in our codebase, we will stick with mixins with your proposal merged, on the contrary, we will use DIP1036 functionalities if merged.

/P