4 ms·

Of course! I will try to explain a problem: 1. suppose there are two layers L0 and L1; 2. also there are an object O1 of type T which is used by L0, but point

Of course! I will try to explain a problem: 1. suppose there are two layers L0 and L1; 2. also there are an object O1 of type T which is used by L0, but pointer A1 to O1 is stored in context C at L1; 3. suppose an object O1 was freed, but after a while an object O2 was created at the __same__ address A1; 4. suppose a context C still has a pointer to A1 as a pointer to an object ____O1____; 5. but A1 doesn't have __O1__ anymore, O1 was freed, right now, A1 contains an object O2; 6. suppose after a while, L1 call API from L0 and pass A1 as a pointer to an object O1. OOPS! We have a bug at this point and we don't even know about it! You may tell that it's unusual situation when O2 created exactly at the same address where O1 was stored. But I can answer that L1 may store objects on the array, say `T Os[100];` . In this case that situation is very possible. So I solved this problem by introducing PTRID. In short, ptr_id_t contains address and unique id which is incremented globally. So using PTRID at stage (6) I can catch a bug! See the code. Note that, PTRID is intended to using for intra-layer calls. Don't use PTRID everywhere because it's a bit costly. Use it for intra-layer calls (i.e. between L0 and L1). I like the following analogy: 1. memory address space is one-dimensional space. 2. but objects created and freed over the time! 3. so it's not really good to use one-dimensional pointer in two dimensional space! 4. that's why PTRID can be imagined as two-dimensional pointer, i.e. a pair (A, T). Where A is address, and T is time (i.e. global ID in my code).

eps 12y ago
Right, thanks. It's a form of pointer virtualization basically. To me personally this falls into the same domain as the "if (0 == x)" notation - it protects against a very specific type of rake that its proponents just happened to have stepped on at some point eariler on. I've been programming in C for over 20 years now and I have never had the issue you are describing. I understand it's possible, but then there's plenty more ways to shoot oneself with C pointers.
- hal9000xp 12y ago
  I worked (and I'm still working) on several big projects which wrote by different people, and by different companies, and at different time. I repeatedly noticed the same pattern where there is a limited linear array of contexts. For example, linear array of user contexts. In this case, it's easy to create a new object in that array just after previous object was destroyed at the same slot (we called an index number in the user context array - slot).

eps 12y ago

Right, thanks. It's a form of pointer virtualization basically. To me personally this falls into the same domain as the "if (0 == x)" notation - it protects against a very specific type of rake that its proponents just happened to have stepped on at some point eariler on. I've been programming in C for over 20 years now and I have never had the issue you are describing. I understand it's possible, but then there's plenty more ways to shoot oneself with C pointers.

hal9000xp 12y ago
I worked (and I'm still working) on several big projects which wrote by different people, and by different companies, and at different time. I repeatedly noticed the same pattern where there is a limited linear array of contexts. For example, linear array of user contexts. In this case, it's easy to create a new object in that array just after previous object was destroyed at the same slot (we called an index number in the user context array - slot).