On Wed, Apr 27, 2005 at 11:35:12PM +0100, Nicholas Clark wrote: > 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?
Long story, partly obscured by the mists of time - the DBI was the first major third-party extension for perl 5.0. But it's well wrapped with macros so whould be easy to change in whatever ways are needed. When DBI is built for ithreads it behaves quite differently, for example. Anyway, driver authors are, these days, encouraged to get the value via the handle rather than the global. Don't worry about the DBI. I'll play with the cards ponie deals me :) Tim.
