Why do private member variables behaved like protected in the same module when creating deriving class?

[Steven Schveighoffer]

On 11/1/18 5:03 PM, Patrick Schluter wrote:
> On Thursday, 1 November 2018 at 20:15:57 UTC, Paul Backus wrote:
>> On Thursday, 1 November 2018 at 19:26:05 UTC, Steven Schveighoffer wrote:
>>>
>>> My testing looks like it's the same:
>>>
>>> #include <stdio.h>
>>> int main()
>>> {
>>>     int arr[5];
>>>     int *ptr = arr + 1; // point at second element so we can do 
>>> negative indexing legally
>>>     int idx1 = 0;
>>>     ptr[--idx1] = 5;
>>>     printf("%d\n", arr[0]); // 5
>>>     size_t idx2 = 0;
>>>     ptr[--idx2] = 6;
>>>     printf("%d\n", arr[0]); // 6
>>>     return 0;
>>> }
>>>
>>
>> `ptr[--idx2]` is undefined behavior (out-of-bounds array access), so 
>> the fact that it works that way is just a coincidence.
> 
> It works also because the optimizer eludes the ptr accesses. So to test 
> the example, at least put -O0.
> 
>          mov     esi, 5
>          mov     edi, OFFSET FLAT:.LC0
>          xor     eax, eax
>          call    printf
>          mov     esi, 6
>          mov     edi, OFFSET FLAT:.LC0
>          xor     eax, eax
>          call    printf

As I said, I didn't use optimizations. And I still didn't get any segfaults.

> 
> and in real life, the erroneaous accesses where I had the index 
> underflowing the array were much more complicated and have not been 
> found for decades. We had noticed sometimes that things were wrong in 
> the documents processed, but it was impossible to trace back were the 
> error was. After refactoring to use more agressively size_t a whole 
> bunch of these glitchy glitches transformed into nice actionable 
> debugable core dumps.

Well, one thing that is very possible, is that if you use uint on a 
64-bit system, you will get segfaults (potentially).

-Steve