Foiled by RT and a too-long body! This is fixed by: Porting/bisect.pl --start v5.17.1 --end v5.17.2 -Dcc='ccache gcc-6' -Dusethreads --expect-fail -- ./perl -Ilib ../36664bis.pl commit 4bac9ae47b5ad7845a24e26b0e95609805de688a Author: Chip Salzenberg <chip@pobox.com> Date: Fri Jun 22 15:18:18 2012 -0700 Magic flags harmonization. In restore_magic(), which is called after any magic processing, all of the public OK flags have been shifted into the private OK flags. Thus the lack of an appropriate public OK flags was used to trigger both get magic and required conversions. This scheme did not cover ROK, however, so all properly written code had to make sure mg_get was called the right number of times anyway. Meanwhile the private OK flags gained a second purpose of marking converted but non-authoritative values (e.g. the IV conversion of an NV), and the inadequate flag shift mechanic broke this in some cases. This patch removes the shift mechanic for magic flags, thus exposing (and fixing) some improper usage of magic SVs in which mg_get() was not called correctly. It also has the side effect of making magic get functions specifically set their SVs to undef if that is desired, as the new behavior of empty get functions is to leave the value unchanged. This is a feature, as now get magic that does not modify its value, e.g. tainting, does not have to be special cased. The changes to cpan/ here are only temporary, for development only, to keep blead working until upstream applies them (or something like them). Thanks to Rik and Father C for review input. :100644 100644 05516688ceca341ac1f63a7f72f63f38c03c18c6 ce7af44486749f954ef01ca9947a30929cd521ea M av.c :040000 040000 e8cce61b676e554a1a21aec8aada38b7cc26616c 979996a498feb6c0af0468e3b2e2509338a04d97 M cpan :100644 100644 fd6683da2622596820f89d44f5cdcbe845cca4a5 e5098b700200db8ea297c685b56dabd24046125a M doio.c :100644 100644 dd6add2bc5d91feeaeac408126c514ebeb0af1fa 1593d1942ba889cc8d6a5e3545d709ee4ea107cb M doop.c :100644 100644 eb81d9c168b2d74c6df878f943c3e89ba69e8c6d 0f19f7c58ee84793ca0d6f0d7c6c893ea1356e4b M embed.fnc :100644 100644 5dca8e33df73a8ea47b4d3739b21f56deefbae09 a010f2dc02d224219f343159afb4f61e642dc599 M embed.h :040000 040000 0550166d7e2deaa7b3a584c1c41d3903d148420f b3a8da6c82519b0e1b8368a90ae1eba06c0d9039 M ext :100644 100644 e0fdc630e913b217b5a02bc6626f3eabc9c464b8 c1652852622992628a77e66ea1edd1b6271a3a77 M gv.c :100644 100644 1c01152496b21d0d22098b5d8567a1ed04e08b76 dd8003e4c2c1023afae2fbd031b2924b48492d94 M mg.c :100644 100644 661c055ffa8462600b4b0fdac2cdd35ff80b9130 0def4ac35f2693bd07e5a45869cfd63d15aae5d0 M pp.c :100644 100644 826a7729384c80b4d4d06d9b8dfbcca962a6eb28 f2119a77d1e273128ba0598e0a66d0e55ccf7851 M pp_ctl.c :100644 100644 1c0acb92b048ca5ebee12876df4ca4e38f45bbff e04d5ca7ed17719696f050da5e2edd0760079c5f M pp_hot.c :100644 100644 f0a799e238b1aa38338d5069190c7a6ec026a06f 76bd1acbf2390cb68a5b06d26c4c21c030201caa M pp_sys.c :100644 100644 946e9fe76eae1a1e9a39d42604bb2d8e4607b612 db957ac4561e4b639425806f2d38ed0acb64dab0 M proto.h :100644 100644 9caaa4da54d5af559c21bad9dd07bd747eabdcb2 25de4ac77f552d59257923960c04ae9039558247 M sv.c :100644 100644 1eeda1cc5d9568221e1f9fbb1499116b549b9c77 c841c3e246bef6a2e0883c6cde920db8a72c477a M sv.h :040000 040000 348277f03b386dfc5c78b85d03f84da724e64f6a b3a087f58519c7355d399e014750df546351abee M t bisect run success That took 1191 seconds. Seems believable. Taking this, because I've written a test, which will be included in my big patch o' tests once I finish this audit. -- Respectfully, Dan Collins --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=36664