December 04, 2020
On Friday, 4 December 2020 at 15:33:40 UTC, Jacob Carlborg wrote:
> On 2020-12-02 18:52, H. S. Teoh wrote:
>
>> [...]
>
> Unfortunately it's still very easy to bypass most safety features in D. Especially since everything is @system by default. All the features of C are still available, one have to pick the D specific features to be safe. I've seen many many times on the forums that people are asking questions with examples containing C style code with raw pointers and calling functions in the C standard library instead of using the D equivalent.

Yes.  I could support a DIP making @safe the default if it did not claim C is @safe.

December 04, 2020
On Friday, 4 December 2020 at 17:52:28 UTC, Bruce Carneal wrote:
> On Friday, 4 December 2020 at 15:33:40 UTC, Jacob Carlborg wrote:
>> On 2020-12-02 18:52, H. S. Teoh wrote:
>>
>>> [...]
>>
>> Unfortunately it's still very easy to bypass most safety features in D. Especially since everything is @system by default. All the features of C are still available, one have to pick the D specific features to be safe. I've seen many many times on the forums that people are asking questions with examples containing C style code with raw pointers and calling functions in the C standard library instead of using the D equivalent.
>
> Yes.  I could support a DIP making @safe the default if it did not claim C is @safe.

That bodyless c function marked as @safe is the biggest hole in that dip that it took a backslash to withdraw the dip.
December 04, 2020
On Friday, 4 December 2020 at 17:52:28 UTC, Bruce Carneal wrote:
> On Friday, 4 December 2020 at 15:33:40 UTC, Jacob Carlborg wrote:
>> On 2020-12-02 18:52, H. S. Teoh wrote:
>>
>>> [...]
>>
>> Unfortunately it's still very easy to bypass most safety features in D. Especially since everything is @system by default. All the features of C are still available, one have to pick the D specific features to be safe. I've seen many many times on the forums that people are asking questions with examples containing C style code with raw pointers and calling functions in the C standard library instead of using the D equivalent.
>
> Yes.  I could support a DIP making @safe the default if it did not claim C is @safe.

That was my problem with the DIP as well.
December 04, 2020
On 12/4/2020 1:24 AM, Timon Gehr wrote:
> The only reason why `HLT` terminates execution of userspace code is that such code does not have sufficient permissions to execute the instruction; in the kernel, it would not do much.

The compiler actually was changed to generate a UD2 instruction (0x0F0B) at the suggestion of (if I remember correctly) Iain.

  https://www.felixcloutier.com/x86/ud

which raises the invalid opcode exception.

  https://github.com/dlang/dmd/blob/master/src/dmd/backend/cod2.d#L5723
December 05, 2020
On Thursday, 3 December 2020 at 10:36:45 UTC, Paulo Pinto wrote:
> On Thursday, 3 December 2020 at 10:12:35 UTC, Max Haughton wrote:
>>> [...]
>
>
> The whole software stack is 100% written in TamaGo (bare metal Go for ARM SoCs), which obviously you didn't bother to read about on the product page.
>
>
>> [...]
>
> Hence why Go has unsafe package for breaking  outside the safety features.
>
> Ironically, what I get from these kind of replies is that companies like F-Secure or PTC/Aicas/Astrobe (*bare metal* Java/Oberon) deliver, whereas here one keeps arguing how bad GC is and it is time to reboot the whole D language for an imaginary crowd to finally adopt it.
>
> In the end, maybe those languages are the ones being adopted.

"Don't put the Geeks in charge of management" 😁

BTW, that's pretty deep.

There are so many unexplored territories in D but we sometimes keep ourselves hooked to the imaginary ones.


> https://github.com/microsoft/MSRC-Security-Research/blob/master/presentations/2020_06_SSTIC/SSTIC2020%20-%20Pursuing%20Durably%20Safe%20Systems%20Software.pdf

December 05, 2020
On Thursday, 3 December 2020 at 10:36:45 UTC, Paulo Pinto wrote:
> On Thursday, 3 December 2020 at 10:12:35 UTC, Max Haughton wrote:
>> On Thursday, 3 December 2020 at 10:07:19 UTC, IGotD- wrote:
>>> On Thursday, 3 December 2020 at 09:04:56 UTC, Paulo Pinto wrote:
>>>>
>>>> F-Secure apparently is living in a phantasy world, https://www.f-secure.com/en/consulting/foundry/usb-armory
>>>
>>> How does this product has to do with safe and unsafe language designs?
>
>
> The whole software stack is 100% written in TamaGo (bare metal Go for ARM SoCs), which obviously you didn't bother to read about on the product page.


It is also severally limited. It looks like it is designed to be used for purpose built tasks, not as a general use operating system. It works because all the complexity of an OS like Linux isn't implemented at all. This is done intentionally. You are comparing apples to oranges and then saying you dont understand why the people talking about apples don't like your oranges.

I don't think any amount of reboot of D will make it more popular with people that are flocking to Rust. D proposed a system that didn't get traction, another language came along proposed something different and did get traction. There are many problems with D as it stands, I use it for smaller hobby projects but it would be a nightmare to use in a larger project that needs to be maintained. Part of that problem is with how the project is managed. Sure everyone has their own opinions of this, and that's one of the reasons that gets brought up about problem. Problems users face aren't taken seriously, it seems management is more concerned with follow trends like implementing borrow ownership than addressing actual problems have brought up. The @safe by default is a good example of that. Rather than listening to the outcry from the community to change one thing, the entire thing was just shut down.



December 06, 2020
On Saturday, 5 December 2020 at 19:32:53 UTC, Testle wrote:
> [discussion including criticism of how "management" dropped DIP 1028 completely rather than amending it to remove the wildly unpopular "C is @safe" verbiage]

Even though I love working on projects that should operate near HW limits, I would like to see defaults favor newcomers and prototyping (@safe, throw, gc).

1028 without the "C is @safe" falsehood could work.

December 08, 2020
On Wednesday, 2 December 2020 at 12:32:02 UTC, M.M. wrote:
> Oh, OK, I see. I was thinking that modern C++ would be equally suitable as D or Rust or any other "modern" language of that sort. But what you explain give me a different view on that.

Putty code shows that traditions are fixable, the problem is to find people who will do it, you might as well look for D or Rust programmers instead.
December 08, 2020
On Sunday, 6 December 2020 at 04:52:19 UTC, Bruce Carneal wrote:
> Even though I love working on projects that should operate near HW limits, I would like to see defaults favor newcomers and prototyping (@safe, throw, gc).
>
> 1028 without the "C is @safe" falsehood could work.

Consider a module with `@safe:` or `@trusted:` at top. The problem with the rule "external C functions can't be @safe" or "can't be @safe by default" is that you do not know why the annotation is at the top of module. It could be because it has been reviewed, or it could be just to get functions calling it to quickly work.

Theoretically, if C code is considered `@safe` by default, you can tell them from each other. No attributes: `@system`, but considered `@safe` for now, meaning you want to review the module in the near future. `@safe` or `@trusted`: someone has checked the module, nothing to worry about.

I don't think this is a good argument, because a comment about whether a review is done is so easy and recommended to add in any case. But then again, it should not make much difference. It is still better to greenwash the C headers as safe (with an appropriate comment about the hack) and use them from `@safe` code, than to mark all your code `@system`. At least you're checking the D code.

So I think that the issue has been exaggregated. Either way, it'd be progress from the current language.
December 09, 2020
On Tuesday, 8 December 2020 at 22:52:29 UTC, Dukc wrote:
> On Sunday, 6 December 2020 at 04:52:19 UTC, Bruce Carneal wrote:
>> Even though I love working on projects that should operate near HW limits, I would like to see defaults favor newcomers and prototyping (@safe, throw, gc).
>>
>> 1028 without the "C is @safe" falsehood could work.
>
> Consider a module with `@safe:` or `@trusted:` at top. The problem with the rule "external C functions can't be @safe" or "can't be @safe by default" is that you do not know why the annotation is at the top of module. It could be because it has been reviewed, or it could be just to get functions calling it to quickly work.
>
> Theoretically, if C code is considered `@safe` by default, you can tell them from each other. No attributes: `@system`, but considered `@safe` for now, meaning you want to review the module in the near future. `@safe` or `@trusted`: someone has checked the module, nothing to worry about.

The problem with this is that there is existing *correct* D code that relies "no attributes" meaning @system, and which would silently become incorrectly-annotated if the default were changed. For example, there are many external @system functions in the D runtime that do not have an explicit @system annotation.

You flip the switch, your tests pass, and then months or years later, you discover that a memory-corruption bug has snuck its way into your @safe code, because no one ever got around to putting an explicit @system annotation on some external function deep in one of your dependencies. How would you react? Personally, I'd jump ship to Rust and never look back.

Of course, you can try to argue that it's the fault of the library maintainer for not realizing that they need to re-review all of their external function declarations--but why should they have to, when the compiler can just as easily flag those functions automatically? Isn't the whole reason we have automatic memory-safety checks in the first place to *avoid* relying on programmer discipline for this kind of thing?