On Thu, Aug 01, 2024 at 06:12:15AM -0400, Jeff King wrote: > On Wed, Jul 17, 2024 at 05:12:25PM -0400, Taylor Blau wrote: > > > After that point, we only need to make two special considerations within > > this function: > > > > - First, the pack_int_id returned to us by `nth_midxed_pack_int_id()` > > is a position in the concatenated lexical order of packs, so we must > > ensure that we subtract `m->num_packs_in_base` before accessing the > > MIDX-local `packs` array. > > > > - Second, we must avoid translating the `pos` back to a MIDX-local > > index, since we use it as an argument to `nth_midxed_offset()` which > > expects a position relative to the concatenated lexical order of > > objects. > > OK. I think this is correct, but this would be another place where we > could use an nth_midxed_offset_one() function if we had one. Yeah. > My thinking was that we'd avoid walking back over the midx chain again. > But I guess we don't actually do that, because our midx_for_object() > will have overwritten our "m" variable, as well. So inside > nth_midxed_offset_one() we'll immediately realize that the global > position is inside the midx we passed in. A little extra arithmetic, but > there's no pointer chasing. Yup, exactly. Thanks, Taylor
