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

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?

On Wednesday, 2 December 2020 at 11:19:08 UTC, M.M. wrote:
>
> Why do you think that D is better than C++ in that respect?

C++ does not have array bounds checking, at least in its original form. C++ added std::array which is kind of wrapper around its static arrays. However, since it is in the STL library you need to compile it and it doesn't play that well bare metal programming. Also when you include STL binary size shoots up the roof. Therefore C++ + STL is often not suitable for kernels and this problem applies for D as well. BetterC is more suitable for kernels.

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.

You need @system code for such kind of tricks and it is relatively easy to track down where @system, or @trusted, code blocks are used for.

On Wednesday, 2 December 2020 at 12:06:57 UTC, IGotD- wrote:
> On Wednesday, 2 December 2020 at 11:19:08 UTC, M.M. wrote:
>>
>> Why do you think that D is better than C++ in that respect?
>
> C++ does not have array bounds checking, at least in its original form. C++ added std::array which is kind of wrapper around its static arrays. However, since it is in the STL library you need to compile it and it doesn't play that well bare metal programming. Also when you include STL binary size shoots up the roof. Therefore C++ + STL is often not suitable for kernels and this problem applies for D as well. BetterC is more suitable for kernels.

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.

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.

On Wednesday, 2 December 2020 at 15:04:29 UTC, IGotD- wrote:
> 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.

D range error actually doesn't allocate memory, it throws a statically allocated object, or with appropriate compile switches, calls an abort function directly.

On Wednesday, 2 December 2020 at 15:13:35 UTC, Adam D. Ruppe wrote:
>
> D range error actually doesn't allocate memory, it throws a statically allocated object, or with appropriate compile switches, calls an abort function directly.

That's interesting and of course people don't this because it is not documented and you of have study the source code in detail to figure this out. Do we have a list what libraries use statically allocated exceptions?

Then comes the question, how is this statically allocated exception placed, on stack or TLS. Is it shared with all libraries that throws RangeError or is it per library?

On Wednesday, 2 December 2020 at 15:19:37 UTC, IGotD- wrote:
> That's interesting and of course people don't this because it is not documented

It is documented that catching an Error will not necessarily work. This is meant to give significant freedom to the implementation.

Note that Error and Exception are two different things. Both are thrown and sometimes caught, but they are two different branches of classes and the language definition treats them differently. Exceptions are meant to be caught and unwind the stack as they work their way up it. Errors are meant to kill the program and thus may or may not unwind the stack and be allowed to be caught. (the `-checkaction` switch to dmd can change throw Error to simply abort the program by a couple means)

> Do we have a list what libraries use statically allocated exceptions?

Library exceptions are free to do this too, but they usually don't since user code is permitted to catch and even retain references to normal exception objects. So it makes it difficult to use tricks like this without breaking user code.

But if a specific library were to do it, it would surely be documented and specially called out for them. No list as far as I know though.

> Then comes the question, how is this statically allocated exception placed, on stack or TLS.

It is implementation defined, so a kernel implementation would surely do it differently if necessary, but in the default impl it goes in TLS. There's one block it reuses for any Error that occurs.

Most common examples of Errors are RangeError for out-of-bounds array access and AssertError for failed assertions.

> Is it shared with all libraries that throws RangeError or is it per library?

This is part of druntime, so unless your libraries have multiple copies of the runtime (which is possible with Windows dlls but not really anywhere else, the system linker will merge the definitions) there's just the one.

If some library decides to `throw new RangeError` of course that would be an ordinary GC'd object. The language doesn't prohibit this but it also doesn't allow it per se, it is still subject to the implementation's whim.

On Wednesday, 2 December 2020 at 15:19:37 UTC, IGotD- wrote:
> On Wednesday, 2 December 2020 at 15:13:35 UTC, Adam D. Ruppe wrote:
>>
>> D range error actually doesn't allocate memory, it throws a statically allocated object, or with appropriate compile switches, calls an abort function directly.
>
> That's interesting and of course people don't this because it is not documented and you of have study the source code in detail to figure this out. Do we have a list what libraries use statically allocated exceptions?

I haven't looked to find whether it's properly documented, but you can find the announcement about the feature that allows choosing the behavior here:

https://dlang.org/changelog/2.084.0.html#checkaction

As for how built-in error handling (I mean out-of-bounds array checks, out-of-memory, etc.) is implemented, it depends on whether betterC [1] is enabled and whether exception support is enabled [2].

[1]: https://github.com/dlang/druntime/blob/v2.094.2/src/core/exception.d#L22
[2]: https://github.com/dlang/druntime/blob/v2.094.2/src/core/exception.d#L16

If exception support is enabled, we do e.g.:

    throw staticError!RangeError(file, line, null);

(The last parameter is used for a chained exceptions, which here is not the case).

The implementation for staticError [3] uses a global TLS variable as storage, though I really don't know why it's implement more along the lines of this:

https://run.dlang.io/gist/PetarKirov/f7b6c3b7e4f8fe10c0a2dbf0d3f44471

[3]: https://github.com/dlang/druntime/blob/v2.094.2/src/core/exception.d#L634

Though I really think it should be implemented like this: