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

[Patrick Schluter]

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;
>> }
>>
>> -Steve
>
> `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

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.