On Tue, Jun 14, 2005 at 11:57:22AM -0600, Jim Cromie wrote: > Nicholas Clark wrote:
> what I dont grok is how removing a field from 1 flavor of the structure > but not the other > doesnt result in havoc. does it relate to this ? (from illguts) > > As a special case we also have /SvIV/ and /SvNV/ types that only have > room for a single integer or a single double value. These are special in > that the PVX/CUR/LEN fields are not present even if the ANY pointer > actually points to the ghostual incarnation of them. This arrangement > makes it possible for code to always access the IVX/NVX fields at a > fixed offset from where the SV field ANY points. Yes, it's the same approach. > >It's intended to save 8 (well, sizeof(NV)) bytes for > >every hash and every array. (and therefore also every pad and every symbol > >table), whilst retaining the constraint that the types > >PV -> PVIV -> PVNV -> PVMG each contain all the elements of the preceding > >types, and that all types larger than PVMG have xmg_stash and xmg_magic at > >the > >same offsets as PVMG. > > > >Nicholas Clark > > > > > > > those constraints sound like they might be upgrade-paths, or perhaps > fast-upgrade paths, > where a plain-old memcpy would work. Does this fit with your vision for > #36076 ? Yes. I can't see a reason why a memcpy won't work, given that that constraint still holds true. Nicholas Clark
