Jump to page: 1 29  
Page
Thread overview
D not considered memory safe
Jul 01
ryuukk_
Jul 02
Monkyyy
Jul 01
Monkyyy
Jul 04
monkyyy
6 days ago
aberba
6 days ago
Lance Bachmeier
4 days ago
Walter Bright
4 days ago
Timon Gehr
2 days ago
Walter Bright
2 days ago
Timon Gehr
2 days ago
Walter Bright
2 days ago
Walter Bright
1 day ago
Walter Bright
1 day ago
Walter Bright
1 day ago
Timon Gehr
1 day ago
Timon Gehr
2 days ago
Walter Bright
1 day ago
Timon Gehr
6 days ago
monkyyy
1 day ago
Imperatorn
5 days ago
aberba
4 days ago
Timon Gehr
4 days ago
monkyyy
4 days ago
Timon Gehr
2 days ago
Walter Bright
2 days ago
Timon Gehr
2 days ago
Walter Bright
1 day ago
Timon Gehr
1 day ago
Timon Gehr
4 days ago
aberba
4 days ago
Timon Gehr
6 days ago
monkyyy
6 days ago
Walter Bright
6 days ago
Lance Bachmeier
6 days ago
Walter Bright
5 days ago
aberba
5 days ago
Martyn
4 days ago
Nick Treleaven
4 days ago
bachmeier
4 days ago
Dom DiSc
4 days ago
bachmeier
3 days ago
Brian Callahan
3 days ago
Lance Bachmeier
3 days ago
Brian Callahan
2 days ago
ryuukk_
2 days ago
Sergey
2 days ago
ryuukk_
2 days ago
Paulo Pinto
4 days ago
monkyyy
3 days ago
Nick Treleaven
3 days ago
monkyyy
3 days ago
aberba
3 days ago
monkyyy
1 day ago
Walter Bright
3 days ago
Nick Treleaven
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