Jump to page: 1 219  
Page
Thread overview
D not considered memory safe
Jul 01
ryuukk_
Jul 02
Monkyyy
Jul 01
Monkyyy
Jul 04
monkyyy
Jul 06
aberba
Jul 17
Dukc
Jul 07
monkyyy
Jul 08
aberba
Jul 08
monkyyy
Jul 08
aberba
Jul 06
monkyyy
Jul 08
aberba
Jul 08
Martyn
Jul 08
bachmeier
Jul 08
Dom DiSc
Jul 08
bachmeier
Jul 10
ryuukk_
Jul 10
Sergey
Jul 10
ryuukk_
Jul 08
monkyyy
Jul 09
monkyyy
Jul 09
aberba
Jul 09
monkyyy
Jul 13
aberba
Jul 19
Dennis
Jul 25
Dennis
Jul 22
claptrap
Jul 13
Dennis
Jul 13
Dennis
Jul 14
Dukc
Jul 26
Dukc
Jul 29
Dukc
Re: [Not really OT] Crowdstrike Analysis: It was a NULL pointer from the memory unsafe C++ language.
Jul 28
Don Allen
Jul 28
Don Allen
Jul 29
Don Allen
Jul 29
Dukc
Jul 29
Dukc
Jul 29
Dukc
Jul 29
bachmeier
Jul 29
Dukc
Jul 25
Serg Gini
Jul 26
aberba
Jul 26
Don Allen
Jul 27
aberba
Jul 29
aberba
Jul 29
aberba
Jul 25
Martin
Jul 23
Kagamin
Jul 29
matheus
July 01

...at least according to Bleeping Computer: https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/

"Memory-unsafe languages are those that do not provide built-in memory management mechanisms, burdening the developer with this responsibility and increasing the likelihood of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython, and D."

July 01

On Monday, 1 July 2024 at 13:40:41 UTC, Brian Callahan wrote:

>

...at least according to Bleeping Computer: https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/

"Memory-unsafe languages are those that do not provide built-in memory management mechanisms, burdening the developer with this responsibility and increasing the likelihood of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython, and D."

Propaganda article, they don't even mention Ada...

July 01

On Monday, 1 July 2024 at 13:40:41 UTC, Brian Callahan wrote:

>

...at least according to Bleeping Computer: https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/

"Memory-unsafe languages are those that do not provide built-in memory management mechanisms, burdening the developer with this responsibility and increasing the likelihood of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython, and D."

It looks like that list comes directly from the CISA report. And it’s not exactly wrong, D is not safe by default. For example they don’t consider rust to be an unsafe language simply because you can use unsafe blocks.

D would I think need to be safe by default and use dip1000 by default to be appropriately labeled safe.

I’m still trying to find out more about the criteria, because I don’t think it discusses how languages were put into these buckets of safe and unsafe.

-Steve

July 02
On 02/07/2024 1:40 AM, Brian Callahan wrote:
> ...at least according to Bleeping Computer: https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/
> 
> "Memory-unsafe languages are those that do not provide built-in memory management mechanisms, burdening the developer with this responsibility and increasing the likelihood of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython, and D."

They are indeed correct that D isn't memory safe however they are conflating multiple things here.

D has no solution to temporal safety which is what Rust has via its borrow checker.

For D the first step to temporal safety would be owner escape analysis which I am currently working on. However it is expensive as to do it properly means you need a DFA.

We do have a GC which does means we have memory safety in terms of lifetimes or non-owning data structures. Nor does this help with the stack.

Data races on the other hand is temporal safety + atomics + locks + immutable. We're missing what is needed to pull all that together right now as one feature.
July 01
On Monday, 1 July 2024 at 13:40:41 UTC, Brian Callahan wrote:
> ...at least according to Bleeping Computer: https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/
>
> "Memory-unsafe languages are those that do not provide built-in memory management mechanisms, burdening the developer with this responsibility and increasing the likelihood of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython, and D."

Yay..... The cia is going to push rust on unpaid devs what could go wrong
July 01
On Mon, Jul 01, 2024 at 02:51:12PM +0000, Monkyyy via Digitalmars-d wrote:
> On Monday, 1 July 2024 at 13:40:41 UTC, Brian Callahan wrote:
> > ...at least according to Bleeping Computer: https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/
> > 
> > "Memory-unsafe languages are those that do not provide built-in memory management mechanisms, burdening the developer with this responsibility and increasing the likelihood of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython, and D."
> 
> Yay..... The cia is going to push rust on unpaid devs what could go wrong

https://xkcd.com/2347/


T

-- 
No! I'm not in denial!
July 02
On 7/1/24 16:00, Steven Schveighoffer wrote:
> 
> D would I think need to be safe by default and use dip1000 by default to be appropriately labeled safe.
> 
> I’m still trying to find out more about the criteria, because I don’t think it discusses how languages were put into these buckets of safe and unsafe.

Well, it cannot be the criteria cited in the OP:
> "Memory-unsafe languages are those that do not provide built-in memory management mechanisms, burdening the developer with this responsibility and increasing the likelihood of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython, and D."

This is plainly incorrect. D has a GC, which is a built-in memory management mechanism.

Safety is not about what you can do, but about what errors you can't make. I guess what's maybe holding D back a bit is the tendency of D programmers to opt for malloc-backed data structures with unestricted `ref` access to elements. DIP1000 can hep but is a bit restricted.

But ultimately technical concerns are probably secondary, and it is mostly about marketing (and what kind of programmers that attracts for building the ecosystem):

> With the D Programming Language, write fast, read fast, and run fast.
> 
> Fast code, fast.

Compare this to:

> A language empowering everyone to build reliable and efficient software.
> Reliability: Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — enabling you to eliminate many classes of bugs at compile-time. 

Technically those guarantees are not fully reliable, but the main webpage says they are right in your face, that's perhaps necessary, or even sufficient.
July 02
On Tuesday, 2 July 2024 at 21:57:14 UTC, Timon Gehr wrote:
>
> This is plainly incorrect. D has a GC, which is a built-in memory management mechanism.

Your thinking logically and not with hype and trends, and that's clearly not what the cia is about, now bad open source dev learn rust
July 02
On 7/1/2024 6:40 AM, Brian Callahan wrote:
> ...at least according to Bleeping Computer: https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/
> 
> "Memory-unsafe languages are those that do not provide built-in memory management mechanisms, burdening the developer with this responsibility and increasing the likelihood of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython, and D."

Now they're complaining that D does not have a gc!
July 03

On Tuesday, 2 July 2024 at 23:33:22 UTC, Walter Bright wrote:

>

On 7/1/2024 6:40 AM, Brian Callahan wrote:

>

...at least according to Bleeping Computer: https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/

"Memory-unsafe languages are those that do not provide built-in memory management mechanisms, burdening the developer with this responsibility and increasing the likelihood of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython, and D."

Now they're complaining that D does not have a gc!

Well, the article is wrong that having a GC prevents all memory safety problems.

What causes all the problems (mostly) is the "built-in memory management" of the stack, and critically, returning references to stack data that will outlive the stack frame. Having a GC isn't enough, every single memory allocation scheme must also be safe to have a safe language.

But to be fair, I don't think the linked report actually discusses the definition of memory safe languages. It's just bleeping computer that adds this (bad) explanation. The CISA report does specifically list D as a memory unsafe language, which I think is a bit harsh.

What I would say with D is that it is much easier to be memory safe, and the compiler provides tools to help with this.

-Steve

« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11