On Tue, 27 Aug 2002, Cliff Woolley wrote: > On Tue, 27 Aug 2002, Gregory (Grisha) Trubetskoy wrote: > > > In other words, instead of > > > > #define APR_RING_SENTINEL(hp, elem, link) \ > > (struct elem *)((char *)(hp) - APR_OFFSETOF(struct elem, link)) > > > > Why not: > > > > #define APR_RING_SENTINEL(hp, elem) \ > > (struct elem *)(hp) > > > > It so happens that the APR_RING_ENTRY is always first in the element > > structure, and so the offset is 0 which is why it works (and the macros > > above yeld same result). But it seems to me that if the APR_RING_ENTRY > > was't first, then the result of APR_RING_SENTINEL could be a pointer to > > somewhere before beginning of head, or some place within head but before > > APR_RING_HEAD, which could be some arbitrary and not necessarily constant > > value. > > That's in fact exactly the point. The sentinel value is not really to be > thought of as a pointer to anything in particular... it's just a magic > number. A ring element structure can be set up so that each element can > be on more than one ring at a time. In that case, each of the rings > attached to any given head needs a unique sentinel value. So while it's > true that this is hardly ever used and is optimized away, it's there just > in case somebody wants to use it. > > Make more sense?
Thanks for the explanation. I guess I am just having a difficult time picturing a scenario where elements are on multiple rings but must share the same head. I suppose there is a small gain in not having to allocate a head structure per ring... IMHO it seems like it would be cleaner if the pointer arithmetic was removed and a restriction was made that each ring requires a unique head element because it's pointer value *is* the sentinel. Then there would be no magic about it (pun intended). Then again I might be missing something... :-) But thanks for taking the time to explain it, Grisha
