On Saturday, 19 October 2013 at 08:25:58 UTC, Maxim Fomin wrote:
> 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.

It's you who made that spin-off, trying to foist it in as yet another example of D's unsafety. I was replying to that.

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

You sounded dissatisfied.

On Saturday, 19 October 2013 at 07:12:26 UTC, Max Samukha wrote:
>
> 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.

So, no cases of memory errors in safe mode of C#? This is what
was expected.

On Saturday, 19 October 2013 at 08:40:08 UTC, Max Samukha wrote:
> On Saturday, 19 October 2013 at 08:25:58 UTC, Maxim Fomin wrote:
>> 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.
>
> It's you who made that spin-off, trying to foist it in as yet another example of D's unsafety. I was replying to that.
>

It seems you missed the point - see second post in page 5.

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.

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

No, I can't be, because I don't buy D promises at all. Man cannot be dissatisfied with something when he expects thing to be broken and it actually happens.

On Saturday, 19 October 2013 at 08:38:52 UTC, Maxim Fomin wrote:
> 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).

Note that you are making similar assumptions about the state of my butt as I did about your dissatisfaction.

>
>> 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.

I haven't heard D ever advertised itself as "faster than C". I heard that immutability/purity provides an opportunity for optimizations not possible in C, and those opportunities have not been realized yet.

>
>> 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.

What's wrong with D's strings?

On Saturday, 19 October 2013 at 08:45:05 UTC, Maxim Fomin wrote:

> 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)".

And we are back to square one - misusing extern(C) and reflection to call the constructor as you showed in #13 does not belong in that collection.

On Saturday, 19 October 2013 at 09:06:35 UTC, Max Samukha wrote:
> On Saturday, 19 October 2013 at 08:38:52 UTC, Maxim Fomin wrote:
>> 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).
>
> Note that you are making similar assumptions about the state of my butt as I did about your dissatisfaction.
>

Right. This talks need to go away.

>>
>>> 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.
>
> I haven't heard D ever advertised itself as "faster than C". I heard that immutability/purity provides an opportunity for optimizations not possible in C, and those opportunities have not been realized yet.

The point is shifted. The claim on D site pages are that it supports safe mode which disallows undefined behavior. Rebuttal are that this it not true - @safe is currently broken due to 1) basing on static type rather than runtime which limits significantly ability to query which things are right and which things are not safe 2) because there are particular cases which shows safety breakages. (Why this is still relevant to the language and not only to compilers was discussed). It is bad to promise something which you are not able to deliver.

In contrary (because C# was mentioned and thread engaged into comparison) C# when it claims to support safety, it actually support safety. Features which it cannot support, are not claimed to be supported. You mentioned performance, so I made a point that C# does not claim to be, for example, faster than C. Such claim does not make much sense, as much as claiming that D safe mode prevents from undefined behavior. It was used for comparison, not for claiming that D really claims to be faster than C.

>>
>>> 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.
>
> What's wrong with D's strings?

Problem is that it uses char array of 1 byte to hold data which has size more than 1 byte. It was discussed in "Inconsistency" thread (http://forum.dlang.org/thread/hoopiiobddbapybbwwoc@forum.dlang.org).

On Saturday, 19 October 2013 at 09:26:53 UTC, Max Samukha wrote:
> On Saturday, 19 October 2013 at 08:45:05 UTC, Maxim Fomin wrote:
>
>> 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)".
>
> And we are back to square one - misusing extern(C) and reflection to call the constructor as you showed in #13 does not belong in that collection.

OK, you can remove extern(c) trick (however, it is not clear, why it shouldn't be counted as a type system hole) and you still have "reflection hole".

I came up with the code in response to Andrei who said that constructor control flow is "primitive but quite adequate" and which "is already implemented and works". What "primitive but quite adequate" does mean is subjective, but it does not really prevent from what it is suppose to prevent. Of course in this case you do not corrupt memory or write to immutable (I am telling this for the third time). The point was made why would you have such constraint if it is easily avoidable? How much sense is in the constraint which does not provide real value (except probably as an exercise in implementing abstract programming theories from academia) nor is properly reinforced?

On Saturday, 19 October 2013 at 10:50:42 UTC, Maxim Fomin wrote:

> OK, you can remove extern(c) trick (however, it is not clear, why it shouldn't be counted as a type system hole) and you still have "reflection hole".
>
> I came up with the code in response to Andrei who said that constructor control flow is "primitive but quite adequate" and which "is already implemented and works". What "primitive but quite adequate" does mean is subjective, but it does not really prevent from what it is suppose to prevent. Of course in this case you do not corrupt memory or write to immutable (I am telling this for the third time). The point was made why would you have such constraint if it is easily avoidable? How much sense is in the constraint which does not provide real value (except probably as an exercise in implementing abstract programming theories from academia) nor is properly reinforced?

The question is what it takes to close every possible hole. .NET designers apparently decided not to close the reflection hole because the cost (in various senses) would be too high.

Am 19.10.2013 17:09, schrieb Max Samukha:
> On Saturday, 19 October 2013 at 10:50:42 UTC, Maxim Fomin wrote:
>
>> OK, you can remove extern(c) trick (however, it is not clear, why it
>> shouldn't be counted as a type system hole) and you still have
>> "reflection hole".
>>
>> I came up with the code in response to Andrei who said that
>> constructor control flow is "primitive but quite adequate" and which
>> "is already implemented and works". What "primitive but quite
>> adequate" does mean is subjective, but it does not really prevent from
>> what it is suppose to prevent. Of course in this case you do not
>> corrupt memory or write to immutable (I am telling this for the third
>> time). The point was made why would you have such constraint if it is
>> easily avoidable? How much sense is in the constraint which does not
>> provide real value (except probably as an exercise in implementing
>> abstract programming theories from academia) nor is properly reinforced?
>
> The question is what it takes to close every possible hole. .NET
> designers apparently decided not to close the reflection hole because
> the cost (in various senses) would be too high.
>

Actually it is very practical, even Java allows for the same functionality.

The ability to disable the security manager and use reflection to access stuff one should actually not be aware of, is a very handy to do unit testing with badly designed libraries.

For example, most Sitecore code uses static classes everywhere.

So either you replicate the whole Sitecore API on both sides (consumer/producer code) to be able to mock all required classes. Or use dirty reflection tricks to rebind method calls, even for private ones.

Too dirty I know, but enterprise code is never pretty.

--
Paulo

On 10/19/2013 10:38 AM, Maxim Fomin wrote:
>> 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.

Keeping being technically incorrect just does not help the discussion. I don't think I _actually_ disagree with you on any major points, but it is hard to judge.

> 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 ...

Just use the proper terms, and you will be understood.