On Tue, May 06, 2014 at 07:58:41PM -0500, Craig A. Berry wrote: > On Tue, May 6, 2014 at 6:01 PM, Steve Hay <[email protected]> wrote: > > On 6 May 2014 21:58, "George Greer" <[email protected]> wrote: > >> > >> Smoke logs available at > >> http://m-l.org/~perl/smoke/perl/linux/blead_g++_quick/logdc396cc29397b262d3cc1473ade4229c84e82ca3.log.gz > >> > >> Automated smoke report for 5.19.12 patch > >> dc396cc29397b262d3cc1473ade4229c84e82ca3 v5.19.11-35-gdc396cc > > [...] > > > >> Byte.c: In function ‘void Encode_XSEncoding(encode_t*)’: > >> Byte.c:24:25: error: invalid conversion from ‘const char*’ to ‘char*’ > >> [-fpermissive] > > > > Sorry folks, looks like upgrading Encode has broken the build again. Good > > CPAN Testers results seem not to be enough; I should have tested with a > > smoke-me branch first... > > > > Everything built and tested fine for me. Does anyone that can reproduce this > > have any spare tuits to fix it? If not then I'll roll back the upgrade. > > (We'll end up with blead customizations either way until another new Encode > > arrives.) > > The tuits are hard to come by, but it's readily reproducible by > configuring with: > > $ ./Configure -Dusedevel -Dcc=g++ -des > > using > > $ g++ --version > g++ (GCC) 4.8.2 > Copyright (C) 2013 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > This on OS X Mavericks but the platform probably doesn't matter. The > error with a wee bit more context is: > > g++ -c -I../Encode -fno-common -DPERL_DARWIN -fwrapv > -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include > -I/opt/local/include -O3 -DVERSION=\"2.04\" -DXS_VERSION=\"2.04\" > "-I../../.." Byte.c > Byte.c: In function 'void Encode_XSEncoding(encode_t*)': > Byte.c:24:25: error: invalid conversion from 'const char*' to 'char*' > [-fpermissive] > SvPVX(iv) = enc->name[0];
The new change seems to be fundamentally Broken. The diff (one of several similar ones) is: - SV *sv = sv_bless(newRV_noinc(newSViv(PTR2IV(enc))),stash); + SV *iv = newSViv(PTR2IV(enc)); + SV *sv = sv_bless(newRV_noinc(iv),stash); int i = 0; + SvFLAGS(iv) |= SVp_POK; + SvPVX(iv) = enc->name[0]; Unless I'm misreading that, it's creating a new SVt_IV, then setting the SVp_POK flag on it and assigning to SvPVX, all without first upgrading to SvPVIV first (nor setting SvLEN etc). Also, since its only an SVt_IV, the IV slot is shared with the PV slot, so the IV value will be overwritten. Since I don't know what the intent of this change is, I don't know how to fix it. -- Dave's first rule of Opera: If something needs saying, say it: don't warble it.
