November 11, 2022
On 11/11/2022 1:32 AM, Siarhei Siamashka wrote:
> ```D
> @safe:
> import std.stdio;
> void main() { readln; }
> ```
> 
> ```
> $ dmd test.d
> test.d(3): Error: `@safe` function `D main` cannot call `@system` function `std.stdio.readln!string.readln`
> /usr/lib/dmd/2.099/import/std/stdio.d(4566): `std.stdio.readln!string.readln` is declared here
> ```

Please report @safe issues to bugzilla:

https://issues.dlang.org/show_bug.cgi?id=23477

November 11, 2022

On Friday, 11 November 2022 at 18:24:46 UTC, Nick Treleaven wrote:

> > >

Just declare main @safe.

Have you missed my comment, which was talking about exactly that?

You didn't mention main.

I apologise. I didn't think that you are unfamiliar with this particular language construct. Check https://dlang.org/spec/attribute.html and search the "affects all declarations until the end" substring to find the relevant part of documentation.

Basically you can put "@safe:" in the beginning of your program and all functions (the main function too) will be @safe by default.

> > >

Memory unsafety is non deterministic. Overflow/underflow is, so it's much less important.

Neither is deterministic. Unless you have strictly deterministic input data.

Whatever the input data, without memory safety you can't trigger the bug through testing alone. It might never occur
on your system, only on your client's.

There may be certain input data patterns, which are not properly stressed by your local testing setup. And only manifest themselves on a client's system. If that's not enough to convince you, there are also many CVEs that mention "integer overflow".

Moreover, paged virtual memory used in modern computers already provides some kind of rudimentary memory safety (with page granularity). Your client may get a "segmentation fault" error with a core dump or a crash dump file, which can be used by you to debug the issue. Debugging an arithmetic overflow bug may be a lot more tricky.

>

That's why the NSA recognises memory safety bugs as categorically worse
than logic bugs or overflow/underflow.

Can you prove this claim by providing a citation?

November 12, 2022

On Friday, 11 November 2022 at 07:03:58 UTC, Paulo Pinto wrote:

>

So it is happening,

"Memory issues in software comprise a large portion of the exploitable vulnerabilities in
existence. NSA advises organizations to consider making a strategic shift from
programming languages that provide little or no inherent memory protection, such as
C/C++, to a memory safe language when possible. Some examples of memory safe
languages are C#, Go, Java, Ruby™, and Swift®."

https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

Eventually this will move from a recomendation, to possible specific certification requirements to still deliver software in such languages.

D is not yet on the list, but who knows, it might make an appearance on some revised version, if someone at NSA is paying attention.

If it becomes a requirement to use memory safe languages, then you know that the U.S. has serious problems if they cannot even choose what language to program in.

November 12, 2022

On Saturday, 12 November 2022 at 02:49:32 UTC, Ruby The Roobster wrote:

>

On Friday, 11 November 2022 at 07:03:58 UTC, Paulo Pinto wrote:

>

So it is happening,

"Memory issues in software comprise a large portion of the exploitable vulnerabilities in
existence. NSA advises organizations to consider making a strategic shift from
programming languages that provide little or no inherent memory protection, such as
C/C++, to a memory safe language when possible. Some examples of memory safe
languages are C#, Go, Java, Ruby™, and Swift®."

https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

Eventually this will move from a recomendation, to possible specific certification requirements to still deliver software in such languages.

D is not yet on the list, but who knows, it might make an appearance on some revised version, if someone at NSA is paying attention.

If it becomes a requirement to use memory safe languages, then you know that the U.S. has serious problems if they cannot even choose what language to program in.

They tried in the past to enforce just one: Ada

Look how that turned out

Even if they internally decided that they'll write all their software in Rust/C#/whatever, they will not try to enforce that on other organizations, simply because the other orgs won't listen and it'll not exactly be cost efficient to actually force them to do so

November 12, 2022
On Friday, 11 November 2022 at 16:10:56 UTC, bachmeier wrote:
> Your comment seems to miss the point. By declaring main @safe, you are ruling out various pieces of the language that are unsafe, which is exactly what you want if safety is the priority. You are arguing instead that @safe doesn't work because it prevents you from doing something that is potentially unsafe.

My comment is precisely on point and you just seem to be unable to see a bigger picture.

NSA is just providing a general safety recommendation. Similar to how some sort of a health organization would generally recommend to eat more vegetables. Or wear a mask in public places, become vaccinated against COVID. Such health organization may list a few COVID-safe countries as an example. Suddenly the residents of country D are upset that their country is not listed as an example of a COVID-safe country. Now looking at the facts, nobody wears a mask in country D (they are arguing that masks are less important than vaccination so it's okay). Also vaccination is available as a free option for any D resident, but it is not being promoted or enforced. Why won't that damn health organization add country D to the list of examples of COVID-safe places in their newsletter? Must be a conspiracy.

Continuing that health organization allegory. One D resident argues that if I care about my personal safety, then I should just become vaccinated myself and everything will be fine. No, this is not fine! And this person just turns a blind eye to a bunch of unvaccinated people roaming in public places and spreading infection in the ecosystem of country D. These other unvaccinated people make me less safe in the D community regardless of my own personal safety countermeasures. Oh, and these people don't wear masks either.

If it's too tricky to decipher, then here are some hints:
  vaccination         => @safe attribute
  masks               => arithmetic overflows checking
  D country           => D language
  health organization => NSA
  D resident          => bachmeier


My point is that as long as the @safe attribute is not used by default (with a way to opt out by overriding it), very few dub package authors and even Phobos authors care about safety and @safe attribute compatibility. The quality of their code also affects the safety of the others in the D ecosystem.

What's up with the standard `readln` function being incompatible with @safe? This even is not a new discovery and nothing was done about it for years: https://forum.dlang.org/post/eaoezjlolelmnxptlqzy@forum.dlang.org

Also why do people even have to write things like https://forum.dlang.org/thread/ilhighccvpjzbblwyqlu@forum.dlang.org about avoiding raw pointers and malloc? Just be @safe and the compiler will complain about potentially dangerous things.
November 12, 2022

On Friday, 11 November 2022 at 15:07:02 UTC, Imperatorn wrote:

> >

TL;DR; You can't really sell a half baked safety nowadays.

I have been involved in high safety applications where human life is at risk.
We use C and C++.

The language is not what determines it, it is the tools, processes and organization.

If you are trying to say that the programming language choice is irrelevant and replacing C/C++ with Rust or D won't improve anything, then I respectfully disagree.

Of course it's possible to implement buggy code in D or Rust. And correct code in C++. The other factors are surely important too and the programming language alone is not a panacea. Still the programming language choice affects the costs and risks.

Other than this, your comment didn't seem to contradict anything that I said. If you think that it did, then please be more specific.

November 12, 2022

On Saturday, 12 November 2022 at 11:31:54 UTC, Siarhei Siamashka wrote:

>

On Friday, 11 November 2022 at 15:07:02 UTC, Imperatorn wrote:

>

[...]

If you are trying to say that the programming language choice is irrelevant and replacing C/C++ with Rust or D won't improve anything, then I respectfully disagree.

Of course it's possible to implement buggy code in D or Rust. And correct code in C++. The other factors are surely important too and the programming language alone is not a panacea. Still the programming language choice affects the costs and risks.

Other than this, your comment didn't seem to contradict anything that I said. If you think that it did, then please be more specific.

You need a verified compiler

November 12, 2022

On Saturday, 12 November 2022 at 13:12:39 UTC, Imperatorn wrote:

>

You need a verified compiler

Who exactly? Me? All readers of this forum? Or are you talking about yourself? Also your statement neither agrees nor disagrees with me.

November 12, 2022
On Fri, Nov 11, 2022 at 07:03:58AM +0000, Paulo Pinto via Digitalmars-d wrote:
> So it is happening,
> 
> "Memory issues in software comprise a large portion of the exploitable vulnerabilities in existence. NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible. Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®."
> 
> https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
[...]

This was inevitable, it was just a matter of time.  Memory-unsafe languages have no long-term future.  In the current landscape of online threats, memory safety is no longer an option, it's an essential requirement.  The day will come when it will no longer be viable to use a memory-unsafe language for anything non-trivial.


T

-- 
Time flies like an arrow. Fruit flies like a banana.
1 2
Next ›   Last »