Jump to page: 1 219  
Page
Thread overview
D not considered memory safe
Jul 01, 2024
Brian Callahan
Jul 01, 2024
ryuukk_
Jul 02, 2024
Timon Gehr
Jul 02, 2024
Monkyyy
Jul 01, 2024
Monkyyy
Jul 01, 2024
H. S. Teoh
Jul 02, 2024
Walter Bright
Jul 03, 2024
Walter Bright
Jul 04, 2024
Sebastian Nibisz
Jul 04, 2024
Lance Bachmeier
Jul 04, 2024
Jonathan M Davis
Jul 04, 2024
monkyyy
Jul 05, 2024
Walter Bright
Jul 06, 2024
Walter Bright
Jul 06, 2024
Sebastian Nibisz
Jul 06, 2024
aberba
Jul 06, 2024
Sebastian Nibisz
Jul 06, 2024
Lance Bachmeier
Jul 08, 2024
Walter Bright
Jul 09, 2024
Timon Gehr
Jul 10, 2024
Walter Bright
Jul 11, 2024
Timon Gehr
Jul 11, 2024
Walter Bright
Jul 11, 2024
Walter Bright
Jul 11, 2024
Walter Bright
Jul 22, 2024
Quirin Schroll
Jul 22, 2024
Walter Bright
Jul 11, 2024
Paolo Invernizzi
Jul 11, 2024
Walter Bright
Jul 11, 2024
Timon Gehr
Jul 11, 2024
Timon Gehr
Jul 15, 2024
Walter Bright
Jul 17, 2024
Dukc
Jul 11, 2024
Walter Bright
Jul 11, 2024
Timon Gehr
Jul 15, 2024
Walter Bright
Jul 17, 2024
Jonathan M Davis
Jul 22, 2024
Walter Bright
Jul 22, 2024
Timon Gehr
Jul 25, 2024
Walter Bright
Jul 25, 2024
Timon Gehr
Jul 07, 2024
monkyyy
Jul 07, 2024
Sebastian Nibisz
Jul 11, 2024
Imperatorn
Jul 08, 2024
aberba
Jul 08, 2024
Timon Gehr
Jul 08, 2024
monkyyy
Jul 08, 2024
Timon Gehr
Jul 10, 2024
Walter Bright
Jul 11, 2024
Timon Gehr
Jul 11, 2024
Walter Bright
Jul 11, 2024
Timon Gehr
Jul 19, 2024
Walter Bright
Jul 11, 2024
Timon Gehr
Jul 19, 2024
Walter Bright
Jul 20, 2024
Timon Gehr
Jul 22, 2024
Walter Bright
Jul 08, 2024
aberba
Jul 08, 2024
Timon Gehr
Jul 06, 2024
monkyyy
Jul 06, 2024
Jonathan M Davis
Jul 06, 2024
Walter Bright
Jul 06, 2024
Lance Bachmeier
Jul 06, 2024
Sebastian Nibisz
Jul 07, 2024
Walter Bright
Jul 08, 2024
aberba
Jul 08, 2024
Martyn
Jul 08, 2024
Nick Treleaven
Jul 08, 2024
bachmeier
Jul 08, 2024
Dom DiSc
Jul 08, 2024
bachmeier
Jul 09, 2024
Brian Callahan
Jul 09, 2024
Lance Bachmeier
Jul 09, 2024
Brian Callahan
Jul 10, 2024
ryuukk_
Jul 10, 2024
Sergey
Jul 10, 2024
ryuukk_
Jul 11, 2024
Paulo Pinto
Jul 08, 2024
monkyyy
Jul 09, 2024
Nick Treleaven
Jul 09, 2024
monkyyy
Jul 09, 2024
aberba
Jul 09, 2024
monkyyy
Jul 11, 2024
Walter Bright
Jul 13, 2024
aberba
Jul 13, 2024
Timon Gehr
Jul 13, 2024
Paolo Invernizzi
Jul 13, 2024
Walter Bright
Jul 13, 2024
Timon Gehr
Jul 19, 2024
Walter Bright
Jul 19, 2024
Dennis
Jul 25, 2024
Walter Bright
Jul 25, 2024
Dennis
Jul 22, 2024
claptrap
Jul 22, 2024
Timon Gehr
Jul 22, 2024
Quirin Schroll
Jul 13, 2024
Dennis
Jul 13, 2024
Walter Bright
Jul 13, 2024
Dennis
Jul 13, 2024
Walter Bright
Jul 14, 2024
Dukc
Jul 25, 2024
Walter Bright
Jul 26, 2024
Dukc
Jul 28, 2024
Walter Bright
Jul 29, 2024
Dukc
Jul 15, 2024
Walter Bright
Jul 17, 2024
Timon Gehr
Jul 19, 2024
Walter Bright
Jul 20, 2024
Timon Gehr
Jul 22, 2024
Walter Bright
Jul 22, 2024
Timon Gehr
Jul 25, 2024
Walter Bright
Jul 25, 2024
Timon Gehr
Re: [Not really OT] Crowdstrike Analysis: It was a NULL pointer from the memory unsafe C++ language.
Jul 25, 2024
Paolo Invernizzi
Jul 25, 2024
Paolo Invernizzi
Jul 25, 2024
Walter Bright
Jul 25, 2024
Timon Gehr
Jul 26, 2024
Paolo Invernizzi
Jul 26, 2024
Guillaume Piolat
Jul 26, 2024
Paolo Invernizzi
Jul 26, 2024
Jordan Wilson
Jul 28, 2024
Timon Gehr
Jul 28, 2024
Don Allen
Jul 28, 2024
Timon Gehr
Jul 28, 2024
Don Allen
Jul 29, 2024
Timon Gehr
Jul 29, 2024
Don Allen
Jul 28, 2024
Sebastiaan Koppe
Jul 29, 2024
Timon Gehr
Jul 29, 2024
Paulo Pinto
Jul 28, 2024
Guillaume Piolat
Jul 29, 2024
Paolo Invernizzi
Jul 29, 2024
Dukc
Jul 29, 2024
Paolo Invernizzi
Jul 29, 2024
Dukc
Jul 29, 2024
Paolo Invernizzi
Jul 29, 2024
Dukc
Jul 29, 2024
bachmeier
Jul 29, 2024
Dukc
Jul 29, 2024
Guillaume Piolat
Jul 29, 2024
Paolo Invernizzi
Jul 29, 2024
Paulo Pinto
Jul 28, 2024
Walter Bright
Jul 28, 2024
Timon Gehr
Jul 28, 2024
Walter Bright
Jul 29, 2024
Timon Gehr
Jul 25, 2024
Serg Gini
Jul 26, 2024
Paolo Invernizzi
Jul 26, 2024
aberba
Jul 26, 2024
Timon Gehr
Jul 26, 2024
Don Allen
Jul 27, 2024
Paolo Invernizzi
Jul 27, 2024
Nick Treleaven
Jul 27, 2024
Paulo Pinto
Jul 27, 2024
aberba
Jul 28, 2024
Timon Gehr
Jul 29, 2024
aberba
Jul 29, 2024
aberba
Jul 30, 2024
Timon Gehr
Jul 25, 2024
Walter Bright
Jul 25, 2024
Timon Gehr
Jul 25, 2024
Timon Gehr
Jul 25, 2024
Martin
Jul 09, 2024
Nick Treleaven
Jul 13, 2024
Timon Gehr
Jul 22, 2024
Quirin Schroll
Jul 19, 2024
Quirin Schroll
Jul 19, 2024
Lance Bachmeier
Jul 19, 2024
H. S. Teoh
Jul 19, 2024
Nick Treleaven
Jul 23, 2024
Kagamin
Jul 29, 2024
matheus
July 01, 2024

...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, 2024

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, 2024

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, 2024
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, 2024
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, 2024
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, 2024
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, 2024
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, 2024
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, 2024

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