On 3/4/15 2:26 AM, Kagamin wrote:
> On Tuesday, 3 March 2015 at 18:38:11 UTC, Steven Schveighoffer wrote:
>> int *myglobal;
>>
>> repeat same code, but access what myglobal points to instead of
>> setting to 42. Memory corruption is what @safe code is trying to
>> prevent. This would lead to memory corruption.
>
> You mean, the class destructor accesses a GC-allocated memory? That's
> indeed unsafe, but unrelated to globals.

Wow, you really aren't getting it. I give up, it's tiring.

-Steve

On Wednesday, 4 March 2015 at 15:39:43 UTC, Steven Schveighoffer wrote:
> Wow, you really aren't getting it. I give up, it's tiring.

Tiring? Did it take that much effort to not say what you mean?

On 3/4/15 11:02 AM, Kagamin wrote:
> On Wednesday, 4 March 2015 at 15:39:43 UTC, Steven Schveighoffer wrote:
>> Wow, you really aren't getting it. I give up, it's tiring.
>
> Tiring? Did it take that much effort to not say what you mean?

No tiring like it is to have to explain obvious details to a child.

In any case, either you are being intentionally obtuse or really ignorant. Either way, I don't have any desire to continue with this conversation.

-Steve

On Wednesday, 4 March 2015 at 17:12:38 UTC, Steven Schveighoffer wrote:
> No tiring like it is to have to explain obvious details to a child.

Safety system is only partially proactive in a sense it doesn't cover all possible scenarios, of one finds a bug, he provides an example, illustrating the bug (did int myglobal do it? if it was a child thing, why it was got wrong?). And scenarios tend to be very non-obvious, especially if one speaks about yet unseen bug. How an unknown bug can be obvious? And you believe, that expressing yourself in Nostradamus style greatly helps make things obvious? What things in safety system are on a child level at all? You should have a longer way to go down to a child argument.

On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
>   private:
>     E[] array;
>     size_t start, end;
>     int* count;

What is the point of keeping start/end? Aren't those baked into the array slice? Not storing start end means not having to do index arithmetic (minor), reducing struct size (always nice). But more importantly, it allows implicit (and conditional) bounds checking (awesome), which actually runs regardless anyways.

Or did I miss something?

On Thursday, 5 March 2015 at 15:20:47 UTC, monarch_dodra wrote:
> On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
>>  private:
>>    E[] array;
>>    size_t start, end;
>>    int* count;
>
> What is the point of keeping start/end? Aren't those baked into the array slice? Not storing start end means not having to do index arithmetic (minor), reducing struct size (always nice). But more importantly, it allows implicit (and conditional) bounds checking (awesome), which actually runs regardless anyways.
>
> Or did I miss something?

`GC.free()` needs a pointer to the start of the allocated block; it will not release memory if it gets an interior pointer. But as far as I can see, one pointer that stores the original address should be enough.

On Thursday, 5 March 2015 at 16:19:09 UTC, Marc Schütz wrote:
> On Thursday, 5 March 2015 at 15:20:47 UTC, monarch_dodra wrote:
>> On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
>>> private:
>>>   E[] array;
>>>   size_t start, end;
>>>   int* count;
>>
>> What is the point of keeping start/end? Aren't those baked into the array slice? Not storing start end means not having to do index arithmetic (minor), reducing struct size (always nice). But more importantly, it allows implicit (and conditional) bounds checking (awesome), which actually runs regardless anyways.
>>
>> Or did I miss something?
>
> `GC.free()` needs a pointer to the start of the allocated block; it will not release memory if it gets an interior pointer. But as far as I can see, one pointer that stores the original address should be enough.

Still, you shouldn't need "end", and bounds checking would "just
work".

On 3/5/15 8:50 AM, monarch_dodra wrote:
> Still, you shouldn't need "end", and bounds checking would "just
> work".

Correct. -- Andrei