Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bleadperl v5.27.0-141-g5d09ee1cb7 breaks DAVIDO/JSON-Tiny-0.56.tar.gz #16023

Closed
p5pRT opened this issue Jun 18, 2017 · 17 comments
Closed

Bleadperl v5.27.0-141-g5d09ee1cb7 breaks DAVIDO/JSON-Tiny-0.56.tar.gz #16023

p5pRT opened this issue Jun 18, 2017 · 17 comments
Labels
BBC Blead Breaks CPAN - changes in blead broke a cpan module(s) distro-All

Comments

@p5pRT
Copy link

p5pRT commented Jun 18, 2017

Migrated from rt.perl.org#131594 (status was 'resolved')

Searchable as RT131594$

@p5pRT
Copy link
Author

p5pRT commented Jun 18, 2017

From @andk

bisect


commit 5d09ee1
Author​: Abigail <abigail@​abigail.be>
Date​: Wed Jun 7 01​:27​:47 2017 +0200

  Fatalize the use of code points above 0xFF for bitwise operators.

diagnostics


Use of strings with code points over 0xFF as arguments to bitwise and (&) operator is not allowed at /tmp/loop_over_bdir-20686-OyGfx4/JSON-Tiny-0.56-0/blib/lib/JSON/Tiny.pm line 272.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 79.
t/20-mojo-json.t .....
Dubious, test returned 255 (wstat 65280, 0xff00)

perl -V


Summary of my perl5 (revision 5 version 27 subversion 1) configuration​:
  Commit id​: 5d09ee1
  Platform​:
  osname=linux
  osvers=4.9.0-2-amd64
  archname=x86_64-linux-ld
  uname='linux k93msid 4.9.0-2-amd64 #1 smp debian 4.9.18-1 (2017-03-30) x86_64 gnulinux '
  config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.0-141-g5d09ee1cb7/af11 -Dmyhostname=k93msid -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Dlibswanted=cl pthread socket inet nsl gdbm dbm malloc dl ld sun m crypt sec util c cposix posix ucb BSD gdbm_compat -Uuseithreads -Duselongdouble -DEBUGGING=-g'
  hint=recommended
  useposix=true
  d_sigaction=define
  useithreads=undef
  usemultiplicity=undef
  use64bitint=define
  use64bitall=define
  uselongdouble=define
  usemymalloc=n
  default_inc_excludes_dot=define
  bincompat5005=undef
  Compiler​:
  cc='cc'
  ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
  optimize='-O2 -g'
  cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
  ccversion=''
  gccversion='6.3.0 20170406'
  gccosandvers=''
  intsize=4
  longsize=8
  ptrsize=8
  doublesize=8
  byteorder=12345678
  doublekind=3
  d_longlong=define
  longlongsize=8
  d_longdbl=define
  longdblsize=16
  longdblkind=3
  ivtype='long'
  ivsize=8
  nvtype='long double'
  nvsize=16
  Off_t='off_t'
  lseeksize=8
  alignbytes=16
  prototype=define
  Linker and Libraries​:
  ld='cc'
  ldflags =' -fstack-protector-strong -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
  libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.24.so
  so=so
  useshrplib=false
  libperl=libperl.a
  gnulibc_version='2.24'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs
  dlext=so
  d_dlsymun=undef
  ccdlflags='-Wl,-E'
  cccdlflags='-fPIC'
  lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector-strong'

Characteristics of this binary (from libperl)​:
  Compile-time options​:
  HAS_TIMES
  PERLIO_LAYERS
  PERL_COPY_ON_WRITE
  PERL_DONT_CREATE_GVSV
  PERL_MALLOC_WRAP
  PERL_OP_PARENT
  PERL_PRESERVE_IVUV
  PERL_USE_DEVEL
  USE_64_BIT_ALL
  USE_64_BIT_INT
  USE_LARGE_FILES
  USE_LOCALE
  USE_LOCALE_COLLATE
  USE_LOCALE_CTYPE
  USE_LOCALE_NUMERIC
  USE_LOCALE_TIME
  USE_LONG_DOUBLE
  USE_PERLIO
  USE_PERL_ATOF
  Built under linux
  Compiled at Jun 6 2017 23​:54​:48
  @​INC​:
  /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.0-141-g5d09ee1cb7/af11/lib/site_perl/5.27.1/x86_64-linux-ld
  /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.0-141-g5d09ee1cb7/af11/lib/site_perl/5.27.1
  /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.0-141-g5d09ee1cb7/af11/lib/5.27.1/x86_64-linux-ld
  /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.0-141-g5d09ee1cb7/af11/lib/5.27.1

--
andreas

@p5pRT
Copy link
Author

p5pRT commented Jun 20, 2017

From @jkeenan

On Sun, 18 Jun 2017 06​:05​:52 GMT, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

bisect
------
commit 5d09ee1
Author​: Abigail <abigail@​abigail.be>
Date​: Wed Jun 7 01​:27​:47 2017 +0200

Fatalize the use of code points above 0xFF for bitwise operators.

diagnostics
-----------
Use of strings with code points over 0xFF as arguments to bitwise and
(&) operator is not allowed at /tmp/loop_over_bdir-20686-OyGfx4/JSON-
Tiny-0.56-0/blib/lib/JSON/Tiny.pm line 272.
# Tests were run but no plan was declared and done_testing() was not
seen.
# Looks like your test exited with 255 just after 79.
t/20-mojo-json.t .....
Dubious, test returned 255 (wstat 65280, 0xff00)

Reported upstream on CPAN.

https://rt.cpan.org/Ticket/Display.html?id=122139

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Jun 20, 2017

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jun 20, 2017

From @Grinnz

FYI, this code was also written by haarg in
daoswald/JSON-Tiny#2 -- I'm not sure how it differs
from the similar code in Mojolicious and JSON​::PP, such that it throws this
error.

On Tue, Jun 20, 2017 at 1​:10 PM, James E Keenan via RT <
perlbug-followup@​perl.org> wrote​:

On Sun, 18 Jun 2017 06​:05​:52 GMT, andreas.koenig.7os6VVqR@​franz.ak.mind.de
wrote​:

bisect
------
commit 5d09ee1
Author​: Abigail <abigail@​abigail.be>
Date​: Wed Jun 7 01​:27​:47 2017 +0200

Fatalize the use of code points above 0xFF for bitwise operators.

diagnostics
-----------
Use of strings with code points over 0xFF as arguments to bitwise and
(&) operator is not allowed at /tmp/loop_over_bdir-20686-OyGfx4/JSON-
Tiny-0.56-0/blib/lib/JSON/Tiny.pm line 272.
# Tests were run but no plan was declared and done_testing() was not
seen.
# Looks like your test exited with 255 just after 79.
t/20-mojo-json.t .....
Dubious, test returned 255 (wstat 65280, 0xff00)

Reported upstream on CPAN.

https://rt.cpan.org/Ticket/Display.html?id=122139

--
James E Keenan (jkeenan@​cpan.org)

---
via perlbug​: queue​: perl5 status​: new
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131594

@p5pRT
Copy link
Author

p5pRT commented Nov 30, 2017

From @cpansprout

On Sat, 17 Jun 2017 23​:05​:52 -0700, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

bisect
------
commit 5d09ee1
Author​: Abigail <abigail@​abigail.be>
Date​: Wed Jun 7 01​:27​:47 2017 +0200

Fatalize the use of code points above 0xFF for bitwise operators.

Also affected JPIERCE/Text-FIGlet-2.19.3.tgz, which is using double bitwise negation (~~) for stringification, an old well-known trick that we might want to consider supporting.

See also​: https://rt.cpan.org/Ticket/Display.html?id=122198

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Nov 30, 2017

From zefram@fysh.org

Father Chrysostomos via RT wrote​:

Also affected JPIERCE/Text-FIGlet-2.19.3.tgz, which is using double
bitwise negation (~~) for stringification, an old well-known trick that
we might want to consider supporting.

No, it's not so sensible that it would be worth preserving. It doesn't
actually work, even on those Perls where it doesn't error (take
~~"\x{ffffffffffffff80}" or ~~"\x{ffffff80}", depending on your word
size). Stringification and scalar context are both operations that we
provide proper operators for. Double complementation is an excessively
cute hack, and the semantics on which it depends are being broken for
good reason.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 5, 2017

From @xsawyerx

On 11/30/2017 05​:41 PM, Zefram wrote​:

Father Chrysostomos via RT wrote​:

Also affected JPIERCE/Text-FIGlet-2.19.3.tgz, which is using double
bitwise negation (~~) for stringification, an old well-known trick that
we might want to consider supporting.
No, it's not so sensible that it would be worth preserving. It doesn't
actually work, even on those Perls where it doesn't error (take
~~"\x{ffffffffffffff80}" or ~~"\x{ffffff80}", depending on your word
size). Stringification and scalar context are both operations that we
provide proper operators for. Double complementation is an excessively
cute hack, and the semantics on which it depends are being broken for
good reason.

However, it is a method used by several prominent modules to avoid the
need to load B. The question is, could (and should) we provide an
alternative.

@p5pRT
Copy link
Author

p5pRT commented Dec 5, 2017

From zefram@fysh.org

Sawyer X wrote​:

However, it is a method used by several prominent modules to avoid the
need to load B.

What are you referring to here? What use of B, and how did double
complement substitute for it?

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 5, 2017

From @xsawyerx

On 12/05/2017 05​:13 PM, Zefram wrote​:

Sawyer X wrote​:

However, it is a method used by several prominent modules to avoid the
need to load B.
What are you referring to here? What use of B, and how did double
complement substitute for it?

It was used instead of B​::SvPV, IIRC. There is no alternative to it.
This seems like a useful thing to be able to do.

@p5pRT
Copy link
Author

p5pRT commented Dec 5, 2017

From zefram@fysh.org

Sawyer X wrote​:

It was used instead of B​::SvPV, IIRC. There is no alternative to it.

Going to need more detail on that. There is no sub by that name.
If the effect you're referring to is stringification, that's achieved
by interpolating into double quotes.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 5, 2017

From @xsawyerx

On 12/05/2017 05​:37 PM, Zefram wrote​:

Sawyer X wrote​:

It was used instead of B​::SvPV, IIRC. There is no alternative to it.
Going to need more detail on that. There is no sub by that name.

Sorry. I meant SvPOK.

@p5pRT
Copy link
Author

p5pRT commented Dec 5, 2017

From zefram@fysh.org

Sawyer X wrote​:

Sorry. I meant SvPOK.

Are you referring to the use of bitwise ops to determine SvNIOK()?
Like this​:

$ perl -le 'sub st { my($v) = @​_; print +($v & "") eq "" ? "string" : "number"; } st(3); $p = "3"; st($p); $p+0; st($p); st("\x{100}")'
number
string
number
string

In this form it still works on blead. The bitwise operators complain
if they have to non-trivially operate on an above-Latin-1 character,
but if the corresponding position in the other string is off the end of
the string then that's apparently fine.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 23, 2017

From @jkeenan

On Tue, 20 Jun 2017 17​:10​:37 GMT, jkeenan wrote​:

On Sun, 18 Jun 2017 06​:05​:52 GMT,
andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

bisect
------
commit 5d09ee1
Author​: Abigail <abigail@​abigail.be>
Date​: Wed Jun 7 01​:27​:47 2017 +0200

Fatalize the use of code points above 0xFF for bitwise operators.

diagnostics
-----------
Use of strings with code points over 0xFF as arguments to bitwise and
(&) operator is not allowed at /tmp/loop_over_bdir-20686-OyGfx4/JSON-
Tiny-0.56-0/blib/lib/JSON/Tiny.pm line 272.
# Tests were run but no plan was declared and done_testing() was not
seen.
# Looks like your test exited with 255 just after 79.
t/20-mojo-json.t .....
Dubious, test returned 255 (wstat 65280, 0xff00)

Reported upstream on CPAN.

https://rt.cpan.org/Ticket/Display.html?id=122139

The author of JSON-Tiny has uploaded a new version of that distribution to CPAN. It now installs against perl 5 blead (tested at v5.27.7-32-ge7e8ce8).

That removes one obstacle to resolving this ticket.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Apr 19, 2018

From @iabyn

Sawyer,

On Tue, Dec 05, 2017 at 04​:25​:04PM +0000, Zefram wrote​:

Sawyer X wrote​:

Sorry. I meant SvPOK.

Are you referring to the use of bitwise ops to determine SvNIOK()?
Like this​:

$ perl -le 'sub st { my($v) = @​_; print +($v & "") eq "" ? "string" : "number"; } st(3); $p = "3"; st($p); $p+0; st($p); st("\x{100}")'
number
string
number
string

In this form it still works on blead. The bitwise operators complain
if they have to non-trivially operate on an above-Latin-1 character,
but if the corresponding position in the other string is off the end of
the string then that's apparently fine.

this ticket is currently marked as a 5.28 blocker. The only reason for
that was your suggestion that ~~ still had a valid use for large-ord
strings, but in the dialogue above you weren't very clear.

Can you confirm (with a clear example), or deny, whether the old behaviour
of bitwise operators (not to die on ord > 0xff) is still needed?

--
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.

@p5pRT
Copy link
Author

p5pRT commented Apr 19, 2018

From @xsawyerx

On 04/19/2018 10​:51 PM, Dave Mitchell wrote​:

Sawyer,

On Tue, Dec 05, 2017 at 04​:25​:04PM +0000, Zefram wrote​:

Sawyer X wrote​:

Sorry. I meant SvPOK.
Are you referring to the use of bitwise ops to determine SvNIOK()?
Like this​:

$ perl -le 'sub st { my($v) = @​_; print +($v & "") eq "" ? "string" : "number"; } st(3); $p = "3"; st($p); $p+0; st($p); st("\x{100}")'
number
string
number
string

In this form it still works on blead. The bitwise operators complain
if they have to non-trivially operate on an above-Latin-1 character,
but if the corresponding position in the other string is off the end of
the string then that's apparently fine.
this ticket is currently marked as a 5.28 blocker. The only reason for
that was your suggestion that ~~ still had a valid use for large-ord
strings, but in the dialogue above you weren't very clear.

Can you confirm (with a clear example), or deny, whether the old behaviour
of bitwise operators (not to die on ord > 0xff) is still needed?

I do not think it is still needed. Thanks!

@p5pRT
Copy link
Author

p5pRT commented Apr 20, 2018

From @iabyn

On Thu, Apr 19, 2018 at 10​:59​:04PM +0200, Sawyer X wrote​:

On 04/19/2018 10​:51 PM, Dave Mitchell wrote​:

Sawyer,

On Tue, Dec 05, 2017 at 04​:25​:04PM +0000, Zefram wrote​:

Sawyer X wrote​:

Sorry. I meant SvPOK.
Are you referring to the use of bitwise ops to determine SvNIOK()?
Like this​:

$ perl -le 'sub st { my($v) = @​_; print +($v & "") eq "" ? "string" : "number"; } st(3); $p = "3"; st($p); $p+0; st($p); st("\x{100}")'
number
string
number
string

In this form it still works on blead. The bitwise operators complain
if they have to non-trivially operate on an above-Latin-1 character,
but if the corresponding position in the other string is off the end of
the string then that's apparently fine.
this ticket is currently marked as a 5.28 blocker. The only reason for
that was your suggestion that ~~ still had a valid use for large-ord
strings, but in the dialogue above you weren't very clear.

Can you confirm (with a clear example), or deny, whether the old behaviour
of bitwise operators (not to die on ord > 0xff) is still needed?

I do not think it is still needed. Thanks!

Ok closing.

--
Hofstadter's Law​: It always takes longer than you expect, even when you
take into account Hofstadter's Law.

@p5pRT p5pRT closed this as completed Apr 20, 2018
@p5pRT
Copy link
Author

p5pRT commented Apr 20, 2018

@iabyn - Status changed from 'open' to 'resolved'

@p5pRT p5pRT added BBC Blead Breaks CPAN - changes in blead broke a cpan module(s) Severity Low distro-All labels Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BBC Blead Breaks CPAN - changes in blead broke a cpan module(s) distro-All
Projects
None yet
Development

No branches or pull requests

1 participant