December 14, 2022
On Wednesday, 14 December 2022 at 21:23:16 UTC, Siarhei Siamashka wrote:
> On Wednesday, 14 December 2022 at 20:36:39 UTC, areYouSureAboutThat wrote:
>> On Wednesday, 14 December 2022 at 13:00:51 UTC, Siarhei Siamashka wrote:
>>>
>>> I guess, you probably want the @trusted parts of Phobos to be annotated as @supertrusted and ignored by this switch, because it's the standard library deserving special privileges? And only complain about the @trusted attribute usage in your own code or in third-party libraries written by plebeians ;-)
>>
>> No. I do not 'trust' the standard library to be 'safe'. Why should I?
>
> Earlier you posted this link: https://learn.microsoft.com/en-us/dotnet/csharp/misc/cs0227
> Why do you 'trust' the standard library and VM of C# to be 'safe'?

That wasn't posted in the context of trusting code, but rather in the context of a thread where someone mentioned that OOP is not suited to building containers. I just posted that link to MS containers to refute that assertion.

In the context of trust, however, no, I do not trust those containers either. Why should I?

I rely (not trust) on the CLR to do it's job properly though.

In C#, safe is default and you cannot escape except through marking code as unsafe, and **additionally**, supplying to the compiler an option that explicately tells the compiler you are ok with compiling in that unsafe code.

But in D, you implicately tell the compiler you completely trust unsafe system code (that has essentially just been annoted as @trusted so that @safe can use it), but is nonetheless unsafe system code) - and you do this just by marking your module as @safe??

No. To me, @safe does not mean I'm completely ok with incorporating unsafe system code into my library (even if someone has annotated it with @trusted).

It's not that I don't ever want it, but I would like to know when it's occuring, and not find out in -release mode :-(

It would be a great auditing tool, if the compiler had this opt-in switch.

I expect its not that hard to do, since the compiler can already do it with @system..@nogc..etc.. I guess I'll just have to work it out :-(

If I do, I'll submit a PR... maybe..

December 14, 2022
On Wednesday, 14 December 2022 at 23:29:00 UTC, areYouSureAboutThat wrote:
>
> That wasn't posted in the context of trusting code, but rather in the context of a thread where someone mentioned that OOP is not suited to building containers. I just posted that link to MS containers to refute that assertion.
>

Oops. A vorrection to my response above, as I mis-read that link (thinking it was pointing to C# containers).

the correct answer to the question posed to me:

"Earlier you posted this link: https://learn.microsoft.com/en-us/dotnet/csharp/misc/cs0227
 Why do you 'trust' the standard library and VM of C# to be 'safe'?"

I don't. But that is not the point I was trying to make.

That link was to demonstrate, that in C# I cannot get untrusted code into my code without my explicately telling the compiler I want it. i.e. just marking C# code as unsafe is not enough. You *also* need to compile with the unsafe option - it cannot just sneak in just cause someone marked it as unsafe.

This is not the case in D, as per my previous post.

Anyway....
December 15, 2022
On Wednesday, 14 December 2022 at 23:56:53 UTC, areYouSureAboutThat wrote:
> On Wednesday, 14 December 2022 at 23:29:00 UTC, areYouSureAboutThat wrote:
>>
>> That wasn't posted in the context of trusting code, but rather in the context of a thread where someone mentioned that OOP is not suited to building containers. I just posted that link to MS containers to refute that assertion.
>>
>
> Oops. A vorrection to my response above, as I mis-read that link (thinking it was pointing to C# containers).
>
> the correct answer to the question posed to me:
>
> "Earlier you posted this link: https://learn.microsoft.com/en-us/dotnet/csharp/misc/cs0227
>  Why do you 'trust' the standard library and VM of C# to be 'safe'?"
>
> I don't. But that is not the point I was trying to make.
>
> That link was to demonstrate, that in C# I cannot get untrusted code into my code without my explicately telling the compiler I want it. i.e. just marking C# code as unsafe is not enough. You *also* need to compile with the unsafe option - it cannot just sneak in just cause someone marked it as unsafe.
>
> This is not the case in D, as per my previous post.
>
> Anyway....

At the very least D should be @safe by default. Slapping a @safe at the top of main isn't good enough, I know it is easy but programmers forget or simply do not know. Out of box experience is vital, @safe by default is part of that IMO if you really want to market as a Rust alternative.

Having said that, I personally don't think Rust is a good approach to SW engineering. It solves one problem well, but that solution negatively impacts other aspects of SW development, some of which are not related to the memory problem. Rust does other things really well too but they are often masked by this everything is a nail approach for average developers.

Most security hacks (that I know of) are not due to C array overruns. Those headliners that usually come from C/C++ code written >10yrs ago. The majority of security breaches are due to human activities, people clicking on fake email links, sharing passwords, leaving computers unlocked, incorrect server and database configuration etc. Rust and @safe will not solve these real world problems.

December 14, 2022
On Thu, Dec 15, 2022 at 01:12:28AM +0000, norm via Digitalmars-d wrote: [...]
> Most security hacks (that I know of) are not due to C array overruns. Those headliners that usually come from C/C++ code written >10yrs ago. The majority of security breaches are due to human activities, people clicking on fake email links, sharing passwords, leaving computers unlocked, incorrect server and database configuration etc. Rust and @safe will not solve these real world problems.

No technology will solve those problems either.  It's a social problem.


T

-- 
IBM = I'll Buy Microsoft!
December 15, 2022
On Wednesday, 14 December 2022 at 23:29:00 UTC, areYouSureAboutThat wrote:
> No. To me, @safe does not mean I'm completely ok with incorporating unsafe system code into my library (even if someone has annotated it with @trusted).
@trusted is not there to make anything @save.
It is there to reduce the amount of code you need to check for correctness.

> It's not that I don't ever want it, but I would like to know when it's occuring,
Then simply search for @trusted. This is really easy and very unlikely to find any false positives. The fewer you find it, the more trustworthy I would consider the code to be.
But to really consider the program @save you need to check these parts yourself - or find someone YOU trust to have checked it.

At least in D you can do that check yourself. In other languages you have no chance other than checking EVERYTHING you include - which tend to be millions of lines of code, so is completely unfeasible.

> It would be a great auditing tool, if the compiler had this opt-in switch.
Don't know how much easier this would be than simply searching for @trusted. As this is already so easy, can't get us much. But at least the compiler can further reduce the search space by indicating which @trusted code is actually used by a program.

But I prefer to do the full search anyway for a new library, to decide if I want to use it or not.
December 15, 2022
On Thursday, 15 December 2022 at 07:19:14 UTC, Dom DiSc wrote:
> In other languages you have no chance other than checking EVERYTHING
> you include - which tend to be millions of lines of code,

If you are even able to get the source code, that is.
December 15, 2022

On Wednesday, 14 December 2022 at 11:45:02 UTC, Dukc wrote:

>
@safe void main() {
    () @trusted { f(); }(); // ok!
}

The difference is that D lets you also write

@trusted void main() {
    f(); // ok!
}

This is really just a nice shorthand for the @safe main with @trusted lambda inside. It's also a better practice, since @trusted in a function signature is easier to spot for a code reviewer than the lambda inside the function.

I don't think so. A search for @trusted finds both.
But the lambda reduces the amount of @trusted code (e.g. all the rest in main() can be @safe, so you don't need to check it).
On the contrary: I would allow @trusted blocks (so that the ugly lambda construct wouldn't be necessary anymore) and forbid @trusted functions altogether - they are simply @system.

This allows to reduce the trusted parts step by step by declaring @system functions as @save and instead mark the few lines in them that do unsafe things as @trusted - until there are no @system functions anymore and the @trusted parts don't contain any calls (except for external calls to parts out of your control because they are from unsafe languages or the source is not available - which should be avoided, unless someone guarantees* them to be save).

Best practice should be to use @trusted around as few lines of code as possible (and of course avoid @system as far as possible).
This is because everything @trusted need to be checked manually and this is very time consuming.

*Meaning: Pays for any damage, if this fails.

December 15, 2022
On Monday, 5 December 2022 at 19:57:39 UTC, H. S. Teoh wrote:
>

well.. for while today, the GC was indeed my enemy...
I was trying to exhaust my heap with this:

module test;

void main()
{
  int *p = new int();
  while (p != null) p = new int();
}

but wtf!
.. rattling my brain...
.. why can I do this in C++ and not in D...wtf..
..wtf... god damn it! why won't you work!

Took me a while to work out I needed to do this first:

import core.memory;
GC.disable;

Nonetheless, I'm glad the GC stepped in, and stopped my heap from overflowing, and preventing my pc from coming to a complete halt ;-)

December 15, 2022
On Thursday, 15 December 2022 at 01:12:28 UTC, norm wrote:
>

> Most security hacks (that I know of) are not due to C array overruns. Those headliners that usually come from C/C++ code written >10yrs ago. The majority of security breaches are due to human activities, people clicking on fake email links, sharing passwords, leaving computers unlocked, incorrect server and database configuration etc. Rust and @safe will not solve these real world problems.

you forget to mention.. 'and programmers blindly using third-party packages'

'An Empirical Study on Production Dependencies in NPM' - 2022

"The problem is that developers struggle to identify what vulnerabilities may affect their software application.."

https://arxiv.org/pdf/2207.14711.pdf
December 15, 2022
On Thursday, 15 December 2022 at 08:01:23 UTC, Dom DiSc wrote:
>
> This is because everything @trusted need to be checked manually and this is very time consuming.
>

manually? that will **never** work.

https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity#p-68