On Saturday, 19 October 2013 at 07:02:21 UTC, Paulo Pinto wrote:
> Am 19.10.2013 08:58, schrieb Max Samukha:
>> On Saturday, 19 October 2013 at 06:24:00 UTC, Paulo Pinto wrote:
>>
>>>
>>> There is nothing unsafe about this code snippet.
>>>
>>
>> Sure. There is nothing unsafe in misusing __traits and extern(C) as well.
>
> There is if the result is
>
> - memory corruption
> - memory leaks no longer visible to the GC
> - program crash
> - ...

No problem, since that was the programmer's explicit purpose. C# provides a ton of backdoors that could lead to what you mentioned in your list.

On Friday, 18 October 2013 at 22:29:45 UTC, Max Samukha wrote:
> On Friday, 18 October 2013 at 20:03:22 UTC, Maxim Fomin wrote:
>
>> (By the way, I don't see why the code above provoked you to C#
>> talks).
>
> Because you:
>
> 1) Mentioned C# as a safer alternative to D.

So, what? If I happen in some another context to mention COBOL, would you bother to remember this and show some piece of COBOL code which is supposedly unsafe or avoids some formal limititation? OK.

> 2) Are using reflection to demonstrate D's unsafety.
>

Actually aggregate name of collection was "(collection of memory errors, type  system breakages and other cases to shoot your foot provided by bugzilla issues, me and other people)". It doesn't mean that each example shows memory error bug. Obviously this case doesn't show unsafity, it shows that the limitation imposed on the language is arbitrary and groundless.

Am 19.10.2013 09:12, schrieb Max Samukha:
> On Saturday, 19 October 2013 at 07:02:21 UTC, Paulo Pinto wrote:
>> Am 19.10.2013 08:58, schrieb Max Samukha:
>>> On Saturday, 19 October 2013 at 06:24:00 UTC, Paulo Pinto wrote:
>>>
>>>>
>>>> There is nothing unsafe about this code snippet.
>>>>
>>>
>>> Sure. There is nothing unsafe in misusing __traits and extern(C) as
>>> well.
>>
>> There is if the result is
>>
>> - memory corruption
>> - memory leaks no longer visible to the GC
>> - program crash
>> - ...
>
> No problem, since that was the programmer's explicit purpose. C#
> provides a ton of backdoors that could lead to what you mentioned in
> your list.

That is why they have to :

- be marked unsafe
- be allowed by the security manager

In D's case it is no different, such code is only to be allowed in @system code and partilly in @thrusted.

--
Paulo

On Saturday, 19 October 2013 at 06:54:32 UTC, Max Samukha wrote:
> On Friday, 18 October 2013 at 23:03:42 UTC, ProgrammingGhost wrote:
>
>> Whats 'wrong' with this code?
>
> Nothing, that's the point. Just like with __traits(getOverloads, this, "__ctor")[0](i).
>
> In my world, safety features of a language are meant to help a fairly reasonable programmer avoid accidental mistakes. Misusing reflection or C interface is not an accidental mistake.

Actual definition of safity in D is "Safe functions are functions that are statically checked to exhibit no possibility of undefined behavior. Undefined behavior is often used as a vector for malicious attacks. " I provided many cases where this does not happen.

On Saturday, 19 October 2013 at 07:12:26 UTC, Max Samukha wrote:
> On Saturday, 19 October 2013 at 07:02:21 UTC, Paulo Pinto wrote:
>> Am 19.10.2013 08:58, schrieb Max Samukha:
>>> On Saturday, 19 October 2013 at 06:24:00 UTC, Paulo Pinto wrote:
>>>
>>>>
>>>> There is nothing unsafe about this code snippet.
>>>>
>>>
>>> Sure. There is nothing unsafe in misusing __traits and extern(C) as well.
>>
>> There is if the result is
>>
>> - memory corruption
>> - memory leaks no longer visible to the GC
>> - program crash
>> - ...
>
> No problem, since that was the programmer's explicit purpose. C# provides a ton of backdoors that could lead to what you mentioned in your list.

This is wrong. Compare safe D and C# in safe, checked mode (I suspect you tried to sell unchecked mode, unmanaged pointers and C++ code invocation as unsafe C# - there are also unsafe features like casts or unions in unsafe D, but this is irrelevant, we are comparing safe mode) and try to come up with examples of memory corruption in C#. At least I showed 4 cases of memory corruption, 4 cases of broken immutable, 2 cases of broken purity in safe D without casts, unions and unchekeced attributes of extern C (which is also hole in type system). So far, you provided only resentment that D was negatively compred with C#.

On Saturday, 19 October 2013 at 07:24:49 UTC, Maxim Fomin wrote:

> Actual definition of safity in D is "Safe functions are functions that are statically checked to exhibit no possibility of undefined behavior. Undefined behavior is often used as a vector for malicious attacks. " I provided many cases where this does not happen.

I know the definition. Aren't we discussing a different matter - your dissatisfaction with the fact that D's control flow analysis does not prevent indirect calls to the constructor?

On Saturday, 19 October 2013 at 07:22:35 UTC, Paulo Pinto wrote:

> That is why they have to :
>
> - be marked unsafe
> - be allowed by the security manager
>
> In D's case it is no different, such code is only to be allowed in @system code and partilly in @thrusted.
>
> --
> Paulo

I understand. However, the case under discussion is about D failing to catch invalid constructor calls. In that regard, granted the C extern is marked @trusted, D is no different than C#.

On Saturday, 19 October 2013 at 07:39:36 UTC, Maxim Fomin wrote:
>
> This is wrong. Compare safe D and C# in safe, checked mode (I suspect you tried to sell unchecked mode, unmanaged pointers and C++ code invocation as unsafe C# - there are also unsafe features like casts or unions in unsafe D, but this is irrelevant, we are comparing safe mode) and try to come up with examples of memory corruption in C#. At least I showed 4 cases of memory corruption, 4 cases of broken immutable, 2 cases of broken purity in safe D without casts, unions and unchekeced attributes of extern C (which is also hole in type system). So far, you provided only resentment that D was negatively compred with C#.

I would agree if:

1. most of the cases you provided were not compiler bugs.
2. C#'s safety didn't have a price.
3. C# had immutable, pure, etc.

On Saturday, 19 October 2013 at 07:42:24 UTC, Max Samukha wrote:
> On Saturday, 19 October 2013 at 07:24:49 UTC, Maxim Fomin wrote:
>
>> Actual definition of safity in D is "Safe functions are functions that are statically checked to exhibit no possibility of undefined behavior. Undefined behavior is often used as a vector for malicious attacks. " I provided many cases where this does not happen.
>
> I know the definition. Aren't we discussing a different matter - your dissatisfaction with the fact that D's control flow analysis does not prevent indirect calls to the constructor?

No. Topic of the thread is Safe D. The point was made that D's
safe mode is not safe at all. Constructor invocation is a
spin-off of the topic.

By the way, no dissatisfaction here, as I don't by D premises at
all.

On Saturday, 19 October 2013 at 08:21:18 UTC, Max Samukha wrote:
> On Saturday, 19 October 2013 at 07:39:36 UTC, Maxim Fomin wrote:
>>
>> This is wrong. Compare safe D and C# in safe, checked mode (I suspect you tried to sell unchecked mode, unmanaged pointers and C++ code invocation as unsafe C# - there are also unsafe features like casts or unions in unsafe D, but this is irrelevant, we are comparing safe mode) and try to come up with examples of memory corruption in C#. At least I showed 4 cases of memory corruption, 4 cases of broken immutable, 2 cases of broken purity in safe D without casts, unions and unchekeced attributes of extern C (which is also hole in type system). So far, you provided only resentment that D was negatively compred with C#.
>
> I would agree if:
>
> 1. most of the cases you provided were not compiler bugs.

Wrong. Most of cases presented are frontend bugs, since all three
known compilers share the same frontend, they are also buggy. In
any case, D is not in a position like C, where there are plenty
of compilers. Most are stack to dmd/gdc/ldc. So, there is no way
to escape from this "just compiler bugs". You can throw "it is
compiler bug, but not language issue" into the trash (please also
D butthurt).

> 2. C#'s safety didn't have a price.

I didn't heard that C# would advertise itself as having speed
'more than C' or any nonsense like D promises about its safety.

> 3. C# had immutable, pure, etc.

But features which it does care to provide, are not bunch of
holes in type system. This is so opposite to D with strings,
shared, AAs, etc.