On Saturday, 23 October 2021 at 11:36:58 UTC, ag0aep6g wrote:
> On 23.10.21 09:53, jfondren wrote:
>> bool encryptsTo(const(char)* key, const(char)* salt, const(char)* hash) @trusted {
>>      import std.string : fromStringz;
>> 
>>      return hash.fromStringz == crypt(key, salt).fromStringz;
>> }
>
> That function can't be @trusted. "Any function that traverses a C string passed as an argument can only be @system."
>
> https://dlang.org/spec/function.html#safe-interfaces

Fair enough. The extra types of the Rust version are one solution to that if a @trusted interface is still wanted. But since in d this function is so trivial, what I actually did was inline it in a safer function that only accepted a string.

On Saturday, 23 October 2021 at 11:36:58 UTC, ag0aep6g wrote:
> On 23.10.21 09:53, jfondren wrote:
>> bool encryptsTo(const(char)* key, const(char)* salt, const(char)* hash) @trusted {
>>      import std.string : fromStringz;
>> 
>>      return hash.fromStringz == crypt(key, salt).fromStringz;
>> }
>
> That function can't be @trusted. "Any function that traverses a C string passed as an argument can only be @system."
>
> https://dlang.org/spec/function.html#safe-interfaces

I think that should be: "Any function that traverses a C string _not verified to be null terminated_ can only be system".

If that check is done in the D wrapper, the function can be correctly trusted.

On 23.10.21 14:01, Paolo Invernizzi wrote:
> On Saturday, 23 October 2021 at 11:36:58 UTC, ag0aep6g wrote:
[...]
>> That function can't be @trusted. "Any function that traverses a C string passed as an argument can only be @system."
>>
>> https://dlang.org/spec/function.html#safe-interfaces
> 
> I think that should be: "Any function that traverses a C string _not verified to be null terminated_ can only be system".
> 
> If that check is done in the D wrapper, the function can be correctly trusted.

You cannot verify that a `char*` is properly terminated. You have to change the parameter type. And when you do that, the caller is not passing a C string as an argument anymore.

On Saturday, 23 October 2021 at 12:11:53 UTC, ag0aep6g wrote:
> On 23.10.21 14:01, Paolo Invernizzi wrote:
>> On Saturday, 23 October 2021 at 11:36:58 UTC, ag0aep6g wrote:
> [...]
>>> That function can't be @trusted. "Any function that traverses a C string passed as an argument can only be @system."
>>>
>>> https://dlang.org/spec/function.html#safe-interfaces
>> 
>> I think that should be: "Any function that traverses a C string _not verified to be null terminated_ can only be system".
>> 
>> If that check is done in the D wrapper, the function can be correctly trusted.
>
> You cannot verify that a `char*` is properly terminated. You have to change the parameter type. And when you do that, the caller is not passing a C string as an argument anymore.

You are right, of course.

It's the caller that needs to assure that the char* was really pointing to a null terminated string, so the caller could be trusted, and the crypt function should be kept system.

Rust has many problems

- ultra slow to compile
- ugly syntax
- sect like community
- NPM like dependency hell, add one dependency, downloads 9488694864 other dependencies 90% of them are unmaintained anymore
- annoying compiler
- unflexible language

On Sat, 2021-10-23 at 08:29 +0000, Imperatorn via Digitalmars-d wrote:
> On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code wrote:
> > Just would like to know you all opinions
> 
> Mainly because you're so unproductive with Rust. It takes so many more keystrokes and thinking to even get anywhere. And for what benefit? A marginally more safe code base? 🤔
> 
> I've written safety critical code for years. Rust isn't even proven in use yet.
> 
> Take a quick look at this: https://www.cvedetails.com/vulnerability-list.php?vendor_id=19029&product_id=48677&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=19&sha=95e4d3703da65f4f319b5bfa6167ff26c6a83c13
> 

We should definitly setup heuristic based fuzzing tho. I guess this is not a good realistic metric for our side because AFAIK we are not being extensively fuzzing either the standard library or the reference compiler implementation.

> And this:
> https://github.com/rust-lang/rust/issues
> 

The scale of the issue list is not so straightforward to measure. There is definitly more activity on Github than on our Bugzilla.

> 
> Shouldn't those list be like... Shorter? 🤔
> 
> D has a balance of productivity and safety. We can improve D and get a nice language. But we need more people and/or focus to do that.
> 
> That's my opinion

I totally agree. Productivity, readability and safety are well balanced for what D offers.


-- 
Sincerely,
Luís Ferreira @ lsferreira.net

On Saturday, 23 October 2021 at 15:26:29 UTC, russhy wrote:
> Rust has many problems
>
> - ultra slow to compile
> - ugly syntax
> - sect like community
> - NPM like dependency hell, add one dependency, downloads 9488694864 other dependencies 90% of them are unmaintained anymore
> - annoying compiler
> - unflexible language

Rust is suffering

https://youtu.be/6x5BNcHyiiI

On Saturday, 23 October 2021 at 15:31:09 UTC, Luís Ferreira wrote:
> On Sat, 2021-10-23 at 08:29 +0000, Imperatorn via Digitalmars-d wrote:
>> [...]
>
> We should definitly setup heuristic based fuzzing tho. I guess this is not a good realistic metric for our side because AFAIK we are not being extensively fuzzing either the standard library or the reference compiler implementation.
>
>> [...]
>
> The scale of the issue list is not so straightforward to measure. There is definitly more activity on Github than on our Bugzilla.
>
>> [...]
>
> I totally agree. Productivity, readability and safety are well balanced for what D offers.

Good point about fuzzing

On Sat, 2021-10-23 at 20:09 +0000, Imperatorn via Digitalmars-d wrote:
> On Saturday, 23 October 2021 at 15:31:09 UTC, Luís Ferreira wrote:
> > On Sat, 2021-10-23 at 08:29 +0000, Imperatorn via Digitalmars-d wrote:
> > > [...]
> > 
> > We should definitly setup heuristic based fuzzing tho. I guess this is not a good realistic metric for our side because AFAIK we are not being extensively fuzzing either the standard library or the reference compiler implementation.
> > 
> > > [...]
> > 
> > The scale of the issue list is not so straightforward to measure. There is definitly more activity on Github than on our Bugzilla.
> > 
> > > [...]
> > 
> > I totally agree. Productivity, readability and safety are well balanced for what D offers.
> 
> Good point about fuzzing

I will add that to my TODO list :)

-- 
Sincerely,
Luís Ferreira @ lsferreira.net