On Sun, Apr 17, 2005 at 05:29:24PM +0100, Tim wrote: > On Mon, Apr 11, 2005 at 11:41:01AM +0100, Nicholas Clark wrote:
> > I think that taking the address of SvIVX() can work (for all the caveats > > that already has, such as don't ever allow anything to upgrade that scalar) > > I can live with that. Thanks. There's the possibility of a problem here - ponie might upgrade things at times when the perl 5 code might not have expected it. [This might be out of date for IVs now that there's _int_val2, but it's probably still true for NVs and particularly for PVs] Specifically to get the representation of IVs tight, I was planning on putting the IV data in the pOBJ and not using any extension area. This means that that there's no room for the traditional perl5 flags. The macros that access things such as SvOK() and SvIOK() would call into PMC vtable methods that knew how to return "true". However, if anything called SvFLAGS() in the old, lvalue sense, I was thinking that the PMC could know to upgrade itself to an internal representation that did have memory sufficient to store flags, and then return the pointer to that address (which the macro SvFLAGS() as today will dereference to create an LVALUE) So there's a possibility that for general space efficiency reasons certain read operations will cause internal data changes which will change the addresses of things such as IVs. At least, there's a possibility in the current vague plans. Taking the address of the insides of scalars seems somewhat, well, sick. Why is it useful, and what would be the slower alternative that you rejected? Nicholas Clark
