On Mon, Jun 1, 2015 at 12:39 PM, Dave Mitchell <davem@iabyn.com> wrote: > On Sun, May 31, 2015 at 05:34:00PM +0200, Max Maischein wrote: > > I did some spelunking in git history and some comparing between 5.20 and > > 5.22-RC2, and here are my findings (as on irc): > > > > There are two errors. One can be easily fixed by reverting the patch > > c910fead7893fe9700031ee59de6b904260b5d69 : > > > > State.xs:3472:9: error: assignment of member 'svt_get' in read-only > object > > orig_sigelem_get = PL_vtbl_sigelem.svt_get; > PL_vtbl_sigelem.svt_get > > = coro_sigelem_get; > > > The change in blead is fine; Coro needs fixing, as suggested by Daniel. > Agreed. I've done this sort of thing before, and I always replaced the vtable instead of overwriting the original one. This would be easy to fix really. > > The second error, I don't understand or what is the real cause: > > > > State.xs:558:29: error: lvalue required as left operand of assignment > > PadlistNAMES (newpadlist) = (PADNAMELIST *)SvREFCNT_inc_NN > (PadlistNAMES > > (padlist)); > > > > This one was likely introduced by > 9b7476d7a269a4d9bb24393ae5c8d75efe2fcab4 , > > but that one doesn't revert easily. > > That commit changed the implementation of PADNAMELISTs, and at the same > time made PadlistNAMES() be rvalue only. There doesn't seem to be part of > the API to allow you to *change* the namelist of a padlist, so I guess > Coro would have to unofficially do something like: > > PadnamelistREFCNT(PadlistNAMES(padlist)); > PadlistARRAY(newpadlist)[0] = PadlistNAMES(padlist); > > It's possible that making PadlistNAMES() rvalue-only was an unintended > side-effect, and that we should fix it for 5.22.1, with something like: > > -#define PadlistNAMES(pl) ((PADNAMELIST *)*PadlistARRAY(pl)) > +#define PadlistNAMES(pl) *((PADNAMELIST **)PadlistARRAY(pl)) > > but that's probably for FC to decide. > Given that it was an lvalue before, I see no reason not to restore that. LeonThread Previous | Thread Next