December 02, 2020
On Wed, Dec 02, 2020 at 12:31:28PM +0000, Paulo Pinto via Digitalmars-d wrote:
> On Wednesday, 2 December 2020 at 11:19:08 UTC, M.M. wrote:
> > On Wednesday, 2 December 2020 at 11:07:54 UTC, Paulo Pinto wrote:
> > > Yet another proof why system languages like D are required to take over OS development.
> > > 
> > > https://googleprojectzero.blogspot.com/2020/12/an-ios-zero-click-radio-proximity.html
> > 
> > Why do you think that D is better than C++ in that respect?
> 
> Bounds checking enabled by default.

And also arrays are fat pointers.

It seems like a minor detail, but it makes a huge difference when the length of the array is always kept together with the pointer to the array contents, and is supported by the language.  I work with C code daily, and I cannot tell you how many times I've seen absolutely terrifying code that simply passes a bare pointer around willy-nilly, making implicit assumptions about array size that, almost inevitably, some user code somewhere violates.  Or the number of times I've fixed bugs involving checking the wrong size against the wrong pointer, because when you have to manually pass them around, it's easy to make mistakes.

The worst is C strings.  The number of bugs I've caught involving (potentially) unterminated strings is absolutely scary.  The worst ones come from unsanitized input, where the code simply *assumes* that some random data read from a file is null-terminated.  Just as bad is code that looks like it was written in the 80's, freely calling strcpy on char* arguments passed in from who knows where, without a care in the world.  And yes, such code is still around. And no, it was not written in the 80's, people still write that garbage *today*, believe it or not. *This* is why such things must be enforced *in the language*, because when people are free to do whatever they want, they inevitably gravitate to the pessimal option.

An equally bad thing about C strings is that utterly evil function known as strncpy.  Why is it evil?  Because it comes with the warning that the result may not be terminated if the target buffer is not large enough to contain the entire string.  And guess how many people gloss over or simply forget that detail?  Yep, I've fixed a whole bunch of bugs caused by that.

And don't get me started with casting void* to all sorts of things willy-nilly. (And in non-trivial code you cannot avoid this, because that's the only way you can write polymorphic code in C.)

C is just a landmine of memory corruption bugs waiting to happen. The incentives are just all wrong.  You have to work hard to make your program memory-safe, and you don't have to lift a finger to incur all sorts of nasty memory bugs.  All it takes is *one* slip-up somewhere in some obscure corner in the code, and you have a memory corruption waiting to happen.

D made a bunch of seemingly-minor, but actually game-changing decisions that eliminate 95% of the above-mentioned problems.  The single biggest one is probably the D array aka fat pointer, as far as memory bugs are concerned.  There are a bunch of others, which others have mentioned. The general design in D is to make the simplest, most naïve code memory-safe, and you have to work at it if you want to bypass that safety net for systems programming reasons.  Which means you'll be thinking harder about your code, and hopefully more aware of potential issues and catch yourself before making slip-ups.  That's the way the incentives should be, not the other way round as it is in C.


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.
December 02, 2020
On Wednesday, 2 December 2020 at 15:04:29 UTC, IGotD- wrote:
> 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.
>
> I also forgot to mention that when there is an out of bound access, both C++ and D throw an exception. Exceptions are usually a big no no in kernels because the potential memory allocation. In kernels you want to reduce and have absolute control over memory allocations. Only the new proposal "lean exceptions" in C++ might be interesting for kernels.

C++ can throw an exception IIF either at() was used, or the STL was compiled with exceptions enabled for operator[]() and the developer aren't using C style arrays in any place of the code.

Otherwise it will corrupt memory just like C, and no exception will be thrown no matter what.
December 03, 2020
On Wednesday, 2 December 2020 at 11:07:54 UTC, Paulo Pinto wrote:
> Yet another proof why system languages like D are required to take over OS development.
>
> https://googleprojectzero.blogspot.com/2020/12/an-ios-zero-click-radio-proximity.html

How many times is this going to happen before people realize it's almost immoral to even continue writing things in C++? I saw a tweet a few days ago where someone pointed out rightly that C++ is not the future because of its memory unsafety, and there were some people trying to tell him he was wrong or being too harsh or that it's just cool to come up with reasons to hate C++ these days. Who would have thought he could be vindicated mere days later.
December 03, 2020
On Wednesday, 2 December 2020 at 11:07:54 UTC, Paulo Pinto wrote:
> system languages like D are required to take over OS development.

Note that d isn't actually safe for kernel code, at least not with the current implementation of @safe (and it would require a fairly large overhaul to fix).

https://forum.dlang.org/thread/qxxdmkhxydcpmdyhrpxd@forum.dlang.org
December 02, 2020
On Thu, Dec 03, 2020 at 01:36:15AM +0000, TheGag96 via Digitalmars-d wrote:
> On Wednesday, 2 December 2020 at 11:07:54 UTC, Paulo Pinto wrote:
> > Yet another proof why system languages like D are required to take over OS development.
> > 
> > https://googleprojectzero.blogspot.com/2020/12/an-ios-zero-click-radio-proximity.html
> 
> How many times is this going to happen before people realize it's almost immoral to even continue writing things in C++? I saw a tweet a few days ago where someone pointed out rightly that C++ is not the future because of its memory unsafety, and there were some people trying to tell him he was wrong or being too harsh or that it's just cool to come up with reasons to hate C++ these days. Who would have thought he could be vindicated mere days later.

Time will eventually prove who's right.  It may not come as fast as we'd hope, but eventually, the weight of evidence against memory-unsafe languages will become so overwhelming that it would speak for itself, we wouldn't need to argue over it anymore.


T

-- 
The best way to destroy a cause is to defend it poorly.
December 03, 2020
On Thursday, 3 December 2020 at 01:36:15 UTC, TheGag96 wrote:
>
> How many times is this going to happen before people realize it's almost immoral to even continue writing things in C++? I saw a tweet a few days ago where someone pointed out rightly that C++ is not the future because of its memory unsafety, and there were some people trying to tell him he was wrong or being too harsh or that it's just cool to come up with reasons to hate C++ these days. Who would have thought he could be vindicated mere days later.

Kernel programming is not the same as application programming. In kernel programming you do so many tricks and quirks that you must operate outside what is considered safe by language designers. Sure bounds checking helps as well as getting rid of those stupid zero terminated strings but a kernel written in a 100% safe language is just fantasy.

Take a look at the Linux page structure (struct page).

https://elixir.bootlin.com/linux/latest/source/include/linux/mm_types.h

It's a structure full of unions, then also we have pointers to other structures some forming a linked list. There is no way you can program this with safe code and the structure requires this because size of this structure is of high importance.

Safe kernel programming just forget it. It's just that C has a bit too few features that can help reducing bugs.

December 03, 2020
On Thursday, 3 December 2020 at 07:28:09 UTC, IGotD- wrote:
> On Thursday, 3 December 2020 at 01:36:15 UTC, TheGag96 wrote:
>> [...]
>
> Kernel programming is not the same as application programming. In kernel programming you do so many tricks and quirks that you must operate outside what is considered safe by language designers. Sure bounds checking helps as well as getting rid of those stupid zero terminated strings but a kernel written in a 100% safe language is just fantasy.
>
> [...]

F-Secure apparently is living in a phantasy world, https://www.f-secure.com/en/consulting/foundry/usb-armory
December 03, 2020
On Thursday, 3 December 2020 at 07:28:09 UTC, IGotD- wrote:
> On Thursday, 3 December 2020 at 01:36:15 UTC, TheGag96 wrote:
>> [...]
>
> Kernel programming is not the same as application programming. In kernel programming you do so many tricks and quirks that you must operate outside what is considered safe by language designers. Sure bounds checking helps as well as getting rid of those stupid zero terminated strings but a kernel written in a 100% safe language is just fantasy.
>
> [...]

Ah, and NVidia is going phantasy land as well, https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-autonomous-driving/
December 03, 2020
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?

On Thursday, 3 December 2020 at 09:16:06 UTC, Paulo Pinto wrote:
>
> Ah, and NVidia is going phantasy land as well, https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-autonomous-driving/

The answer is still no, you cannot write a kernel in a safe language without breaking  outside the safety features. You can write a kernel in Rust but many portions must be in unsafe mode, for example unions are not safe in Rust. Ada and SPARK are likely to be good languages if you want to create stable SW however like I wrote before in order to write a kernel you're likely to step outside the safety harness in these languages as well. Kernel SW is inherently unsafe.
December 03, 2020
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?
>
> On Thursday, 3 December 2020 at 09:16:06 UTC, Paulo Pinto wrote:
>>
>> Ah, and NVidia is going phantasy land as well, https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-autonomous-driving/
>
> The answer is still no, you cannot write a kernel in a safe language without breaking  outside the safety features. You can write a kernel in Rust but many portions must be in unsafe mode, for example unions are not safe in Rust. Ada and SPARK are likely to be good languages if you want to create stable SW however like I wrote before in order to write a kernel you're likely to step outside the safety harness in these languages as well. Kernel SW is inherently unsafe.

Just because you have to take some liberties with the safety features doesn't mean you have to avoid them entirely. If you look at the Linux kernel, a huge amount of the code could nearly be in userspace when you take into account how it actually works. For example, implementing a high level system call like perf_event_open is practically doable as a library with the right msr set.

With a safe language you can carefully contain and test unsafe constructs, with C you don't even have the option of doing that.