Inconsistency in Data::Dumper integer representations #10174

p5pRT · 2010-02-14T02:03:19Z

Migrated from rt.perl.org#72794 (status was 'open')

Searchable as RT72794$

p5pRT · 2010-02-14T02:03:20Z

From @pjscott

The quoting of integers by Data::Dumper has changed over the years;
5.6.1 and 5.8.0 quoted them; 5.8.1 thru 5.8.8 did not quote them.
But 5.11 changes its mind depending on the value of the integer,
according to some rule I cannot fathom. Observe:

$ perl -MData::Dumper -e 'print Dumper $_**2 for 1..10'
$VAR1 = '1';
$VAR1 = '4';
$VAR1 = 9;
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 36;
$VAR1 = 49;
$VAR1 = '64';
$VAR1 = 81;
$VAR1 = 100;

Whatever the result is supposed to be, I'm fairly sure it's not that.
It's somewhere in the XS, probably DD_Dump(); it doesn't happen in
pure Perl mode, and the DD object that's created is the same for the
two different cases. And it has to be an integer from a calculation:

$ perl -MData::Dumper -e 'print Dumper $_ for 4**2,5**2,16,25'
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 16;
$VAR1 = 25;

Pure Perl mode does not quote them, which would be my vote for the
correct behavior.

$ perl -V
Summary of my perl5 (revision 5 version 11 subversion 4) configuration:

Platform:
osname=linux, osvers=2.6.27.24-170.2.68.fc10.i686, archname=i686-linux
uname='linux bugs 2.6.27.24-170.2.68.fc10.i686 #1 smp wed may 20
23:10:16 edt 2009 i686 i686 i386 gnulinux '
config_args='-des -Dusedevel -Uversiononly'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include'
ccversion='', gccversion='4.3.2 20081105 (Red Hat 4.3.2-7)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.9.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.9'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib
-fstack-protector'

Characteristics of this binary (from libperl):
Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP PERL_USE_DEVEL
USE_LARGE_FILES USE_PERLIO
Built under linux
Compiled at Feb 2 2010 14:56:58
@INC:
/usr/local/lib/perl5/site_perl/5.11.4/i686-linux
/usr/local/lib/perl5/site_perl/5.11.4
/usr/local/lib/perl5/5.11.4/i686-linux
/usr/local/lib/perl5/5.11.4
.

p5pRT · 2010-02-15T15:37:18Z

From @demerphq

On 14 February 2010 03:03, Peter Scott <perlbug-followup@perl.org> wrote:

# New Ticket Created by Peter Scott
# Please include the string: [perl #72794]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=72794 >

The quoting of integers by Data::Dumper has changed over the years;
5.6.1 and 5.8.0 quoted them; 5.8.1 thru 5.8.8 did not quote them.
But 5.11 changes its mind depending on the value of the integer,
according to some rule I cannot fathom. Observe:

$ perl -MData::Dumper -e 'print Dumper $_**2 for 1..10'
$VAR1 = '1';
$VAR1 = '4';
$VAR1 = 9;
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 36;
$VAR1 = 49;
$VAR1 = '64';
$VAR1 = 81;
$VAR1 = 100;

Whatever the result is supposed to be, I'm fairly sure it's not that.
It's somewhere in the XS, probably DD_Dump(); it doesn't happen in
pure Perl mode, and the DD object that's created is the same for the
two different cases. And it has to be an integer from a calculation:

$ perl -MData::Dumper -e 'print Dumper $_ for 4**2,5**2,16,25'
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 16;
$VAR1 = 25;

Pure Perl mode does not quote them, which would be my vote for the
correct behavior.

The thing is that the XS mode is supposed to be fast, and what you
want is done by using a regex on every non reference value, which is
slow.

IMO, use of the "Useqq" option is the correct way to get consistent
and predictable results - which actually forces the Perl
implementation because the XS implementation only knows _very_ simple
escaping rules for strings (again for speed purposes).

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2010-02-15T15:37:19Z

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

p5pRT · 2010-02-15T15:47:52Z

From @demerphq

On 14 February 2010 20:06, Dave Mitchell <davem@iabyn.com> wrote:

On Sun, Feb 14, 2010 at 01:26:24PM -0500, Ronald J Kimball wrote:

On Sat, Feb 13, 2010 at 06:03:20PM -0800, Peter Scott wrote:

# New Ticket Created by Peter Scott
# Please include the string: [perl #72794]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=72794 >

The quoting of integers by Data::Dumper has changed over the years;
5.6.1 and 5.8.0 quoted them; 5.8.1 thru 5.8.8 did not quote them.
But 5.11 changes its mind depending on the value of the integer,
according to some rule I cannot fathom. Observe:

$ perl -MData::Dumper -e 'print Dumper $_**2 for 1..10'
$VAR1 = '1';
$VAR1 = '4';
$VAR1 = 9;
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 36;
$VAR1 = 49;
$VAR1 = '64';
$VAR1 = 81;
$VAR1 = 100;

The only pattern I see offhand is that the quoted numbers are powers of 2.
Does that hold with other types of calculations?

It appears that the powers of two are NOK, while the others are NOK, and
I guess Dumper's behaviour varies on IOK/NOK ??

From the latest DD on cpan:

/* Changes in 5.7 series mean that now IOK is only set if scalar is
precisely integer but in 5.6 and earlier we need to do a more
complex test */
#if PERL_VERSION <= 6
#define DD_is_integer(sv) (SvIOK(sv) && (SvIsUV(val) ? SvUV(sv) ==
SvNV(sv) : SvIV(sv) == SvNV(sv)))
#else
#define DD_is_integer(sv) SvIOK(sv)
#endif

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2010-02-15T15:48:24Z

From @demerphq

On 15 February 2010 16:35, demerphq <demerphq@gmail.com> wrote:

On 14 February 2010 03:03, Peter Scott <perlbug-followup@perl.org> wrote:

# New Ticket Created by Peter Scott
# Please include the string: [perl #72794]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=72794 >

The quoting of integers by Data::Dumper has changed over the years;
5.6.1 and 5.8.0 quoted them; 5.8.1 thru 5.8.8 did not quote them.
But 5.11 changes its mind depending on the value of the integer,
according to some rule I cannot fathom. Observe:

$ perl -MData::Dumper -e 'print Dumper $_**2 for 1..10'
$VAR1 = '1';
$VAR1 = '4';
$VAR1 = 9;
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 36;
$VAR1 = 49;
$VAR1 = '64';
$VAR1 = 81;
$VAR1 = 100;

Whatever the result is supposed to be, I'm fairly sure it's not that.
It's somewhere in the XS, probably DD_Dump(); it doesn't happen in
pure Perl mode, and the DD object that's created is the same for the
two different cases. And it has to be an integer from a calculation:

$ perl -MData::Dumper -e 'print Dumper $_ for 4**2,5**2,16,25'
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 16;
$VAR1 = 25;

Pure Perl mode does not quote them, which would be my vote for the
correct behavior.

The thing is that the XS mode is supposed to be fast, and what you
want is done by using a regex on every non reference value, which is
slow.

IMO, use of the "Useqq" option is the correct way to get consistent
and predictable results - which actually forces the Perl
implementation because the XS implementation only knows _very_ simple
escaping rules for strings (again for speed purposes).

Although I note that it now does a fair bit more than it used to.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2010-02-15T16:30:33Z

From @Tux

On Mon, 15 Feb 2010 16:35:35 +0100, demerphq <demerphq@gmail.com> wrote:

On 14 February 2010 03:03, Peter Scott <perlbug-followup@perl.org> wrote:

# New Ticket Created by Peter Scott
# Please include the string: [perl #72794]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=72794 >

The quoting of integers by Data::Dumper has changed over the years;
5.6.1 and 5.8.0 quoted them; 5.8.1 thru 5.8.8 did not quote them.
But 5.11 changes its mind depending on the value of the integer,
according to some rule I cannot fathom. Observe:

$ perl -MData::Dumper -e 'print Dumper $_**2 for 1..10'
$VAR1 = '1';
$VAR1 = '4';
$VAR1 = 9;
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 36;
$VAR1 = 49;
$VAR1 = '64';
$VAR1 = 81;
$VAR1 = 100;

Whatever the result is supposed to be, I'm fairly sure it's not that.
It's somewhere in the XS, probably DD_Dump(); it doesn't happen in
pure Perl mode, and the DD object that's created is the same for the
two different cases. And it has to be an integer from a calculation:

$ perl -MData::Dumper -e 'print Dumper $_ for 4**2,5**2,16,25'
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 16;
$VAR1 = 25;

Pure Perl mode does not quote them, which would be my vote for the
correct behavior.

The thing is that the XS mode is supposed to be fast, and what you
want is done by using a regex on every non reference value, which is
slow.

IMO, use of the "Useqq" option is the correct way to get consistent
and predictable results - which actually forces the Perl
implementation because the XS implementation only knows _very_ simple
escaping rules for strings (again for speed purposes).

And even Useqq is not convenient enough :)

--8<--- dd.pl
use strict;
use warnings;

use Data::Dumper;

my $hash = {
foo => "EUR \x{20ac}",
bar => "\xe2\x82\xac",
"EUR \x{20ac}" => "foo",
"\xe2\x82\xac" => "bar",
};

$Data::Dumper::Sortkeys = 1;
$Data::Dumper::Indent = 1;
$Data::Dumper::Quotekeys = 0;
$Data::Dumper::Terse = 1;

$Data::Dumper::Useqq = 0;
print Dumper $hash;

$Data::Dumper::Useqq = 1;
print Dumper $hash;
-->8---

$ perl dd.pl
{
"EUR \x{20ac}" => 'foo',
bar => '€',
foo => "EUR \x{20ac}",
'€' => 'bar'
}
{
"EUR \x{20ac}" => "foo",
bar => "\342\202\254",
foo => "EUR \x{20ac}",
"\342\202\254" => "bar"
}

With or without binmode :utf8 or -C3, I cannot make Data::Dumper
show \x{20ac} as a euro character (or as junk when printed to a
non-utf device), which is something I quite often want.

I can also imagine Useqq being split for use to keys and/or values

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

p5pRT · 2010-02-15T16:34:43Z

From @demerphq

On 15 February 2010 17:28, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:

On Mon, 15 Feb 2010 16:35:35 +0100, demerphq <demerphq@gmail.com> wrote:

On 14 February 2010 03:03, Peter Scott <perlbug-followup@perl.org> wrote:

# New Ticket Created by Peter Scott
# Please include the string: [perl #72794]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=72794 >

The quoting of integers by Data::Dumper has changed over the years;
5.6.1 and 5.8.0 quoted them; 5.8.1 thru 5.8.8 did not quote them.
But 5.11 changes its mind depending on the value of the integer,
according to some rule I cannot fathom. Observe:

$ perl -MData::Dumper -e 'print Dumper $_**2 for 1..10'
$VAR1 = '1';
$VAR1 = '4';
$VAR1 = 9;
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 36;
$VAR1 = 49;
$VAR1 = '64';
$VAR1 = 81;
$VAR1 = 100;

Whatever the result is supposed to be, I'm fairly sure it's not that.
It's somewhere in the XS, probably DD_Dump(); it doesn't happen in
pure Perl mode, and the DD object that's created is the same for the
two different cases. And it has to be an integer from a calculation:

$ perl -MData::Dumper -e 'print Dumper $_ for 4**2,5**2,16,25'
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 16;
$VAR1 = 25;

Pure Perl mode does not quote them, which would be my vote for the
correct behavior.

The thing is that the XS mode is supposed to be fast, and what you
want is done by using a regex on every non reference value, which is
slow.

IMO, use of the "Useqq" option is the correct way to get consistent
and predictable results - which actually forces the Perl
implementation because the XS implementation only knows _very_ simple
escaping rules for strings (again for speed purposes).

And even Useqq is not convenient enough :)

--8<--- dd.pl
use strict;
use warnings;

use Data::Dumper;

my $hash = {
foo => "EUR \x{20ac}",
bar => "\xe2\x82\xac",
"EUR \x{20ac}" => "foo",
"\xe2\x82\xac" => "bar",
};

$Data::Dumper::Sortkeys = 1;
$Data::Dumper::Indent = 1;
$Data::Dumper::Quotekeys = 0;
$Data::Dumper::Terse = 1;

$Data::Dumper::Useqq = 0;
print Dumper $hash;

$Data::Dumper::Useqq = 1;
print Dumper $hash;
-->8---

$ perl dd.pl
{
"EUR \x{20ac}" => 'foo',
bar => '€',
foo => "EUR \x{20ac}",
'€' => 'bar'
}
{
"EUR \x{20ac}" => "foo",
bar => "\342\202\254",
foo => "EUR \x{20ac}",
"\342\202\254" => "bar"
}

With or without binmode :utf8 or -C3, I cannot make Data::Dumper
show \x{20ac} as a euro character (or as junk when printed to a
non-utf device), which is something I quite often want.

I can also imagine Useqq being split for use to keys and/or values

I think there is a comment about that in the latest versions code.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2010-02-24T14:02:49Z

From @iabyn

On Sun, Feb 14, 2010 at 07:06:47PM +0000, Dave Mitchell wrote:

It appears that the powers of two are NOK, while the others are IOK

At a slight tangent to the original bug, this appears to be a mistake in
pp_pow(): the combo (integer_power_of_two ** integer) is special-cased,
and calculates the results using NV, but at the end tries to convert the
result back to IV if possible - but the code appears to have a cut+paste
typo - it coerces the original arg, not the result:

SETn( result );
SvIV_please(svr); <=== should be SvIV_please(result)

something to fix up post 5.12

--
A major Starfleet emergency breaks out near the Enterprise, but
fortunately some other ships in the area are able to deal with it to
everyone's satisfaction.
-- Things That Never Happen in "Star Trek" #13

p5pRT · 2010-02-24T14:20:54Z

From @iabyn

On Mon, Feb 15, 2010 at 05:32:59PM +0100, demerphq wrote:
[snip various stuff about useqq etc ]

Assming that the bug in pp_pow gets fixed, then the only issue with
Data::Dumper is that it unnecessarily quotes NVs:

$ p -MData::Dumper -e'print Dumper 1, 2.2'
$VAR1 = 1;
$VAR2 = '2.2';

which presumably could be regarded as an enhancement rather than a bug.

--
Wesley Crusher gets beaten up by his classmates for being a smarmy git,
and consequently has a go at making some friends of his own age for a
change.
-- Things That Never Happen in "Star Trek" #18

p5pRT · 2010-02-24T15:00:15Z

From @nwc10

On Wed, Feb 24, 2010 at 02:01:34PM +0000, Dave Mitchell wrote:

On Sun, Feb 14, 2010 at 07:06:47PM +0000, Dave Mitchell wrote:

It appears that the powers of two are NOK, while the others are IOK

At a slight tangent to the original bug, this appears to be a mistake in
pp_pow(): the combo (integer_power_of_two ** integer) is special-cased,
and calculates the results using NV, but at the end tries to convert the
result back to IV if possible - but the code appears to have a cut+paste
typo - it coerces the original arg, not the result:
SETn$ result $;
SvIV\_please$svr$; \<=== should be SvIV\_please$result$
something to fix up post 5.12

Mmm, that likely would be my mistake.

But it being there didn't affect the original problem that we were trying to
'solve' - int(2**31) was returning an odd number on Irix under some
configurations before this 'fix'.

Nicholas Clark

p5pRT · 2013-02-20T01:57:57Z

From @jkeenan

On Mon Feb 15 07:37:18 2010, demerphq wrote:

On 14 February 2010 03:03, Peter Scott <perlbug-followup@perl.org> wrote:

# New Ticket Created by �Peter Scott
# Please include the string: �[perl #72794]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=72794 >

The quoting of integers by Data::Dumper has changed over the years;
5.6.1 and 5.8.0 quoted them; 5.8.1 thru 5.8.8 did not quote them.
But 5.11 changes its mind depending on the value of the integer,
according to some rule I cannot fathom. �Observe:

$ perl -MData::Dumper -e 'print Dumper $_**2 for 1..10'
$VAR1 = '1';
$VAR1 = '4';
$VAR1 = 9;
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 36;
$VAR1 = 49;
$VAR1 = '64';
$VAR1 = 81;
$VAR1 = 100;

Whatever the result is supposed to be, I'm fairly sure it's not that.
It's somewhere in the XS, probably DD_Dump(); it doesn't happen in
pure Perl mode, and the DD object that's created is the same for the
two different cases. �And it has to be an integer from a calculation:

$ perl -MData::Dumper -e 'print Dumper $_ for 4**2,5**2,16,25'
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 16;
$VAR1 = 25;

Pure Perl mode does not quote them, which would be my vote for the
correct behavior.

The thing is that the XS mode is supposed to be fast, and what you
want is done by using a regex on every non reference value, which is
slow.

IMO, use of the "Useqq" option is the correct way to get consistent
and predictable results - which actually forces the Perl
implementation because the XS implementation only knows _very_ simple
escaping rules for strings (again for speed purposes).

cheers,
Yves

I reviewed this older ticket this evening. The somewhat peculiar
behavior of Data::Dumper with respect to quoting of numbers is still
present in Perl 5.16. However, demerphq's argument that this is a
trade-off which the XS version of Data::Dumper makes for speed is also
still cogent.

##########
$ perl -MData::Dumper -e 'print Dumper $_**2 for 1..10'
$VAR1 = '1';
$VAR1 = '4';
$VAR1 = 9;
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 36;
$VAR1 = 49;
$VAR1 = '64';
$VAR1 = 81;
$VAR1 = 100;

$ perl -MData::Dumper -e '$Data::Dumper::Useqq=1;print Dumper $_**2 for
1..10'
$VAR1 = 1;
$VAR1 = 4;
$VAR1 = 9;
$VAR1 = 16;
$VAR1 = 25;
$VAR1 = 36;
$VAR1 = 49;
$VAR1 = 64;
$VAR1 = 81;
$VAR1 = 100;

$ perl -MData::Dumper -e 'print Dumper $_ for 4**2,5**2,16,25'
$VAR1 = '16';
$VAR1 = 25;
$VAR1 = 16;
$VAR1 = 25;

$ perl -MData::Dumper -e '$Data::Dumper::Useqq=1;print Dumper $_ for
4**2,5**2,16,25'
$VAR1 = 16;
$VAR1 = 25;
$VAR1 = 16;
$VAR1 = 25;
##########

The discussion, as these things tend to do, wandered off from the
original complaint.

I recommend that, unless someone feels strongly enough about this issue
to submit a documentation patch, this issue be closed. (Taking the
ticket for that purpose.)

Thank you very much.
Jim Keenan

p5pRT · 2013-02-20T02:04:16Z

From @demerphq

On 24 February 2010 15:20, Dave Mitchell <davem@iabyn.com> wrote:

On Mon, Feb 15, 2010 at 05:32:59PM +0100, demerphq wrote:
[snip various stuff about useqq etc ]

Assming that the bug in pp_pow gets fixed, then the only issue with
Data::Dumper is that it unnecessarily quotes NVs:

$ p -MData::Dumper -e'print Dumper 1, 2.2'
$VAR1 = 1;
$VAR2 = '2.2';

which presumably could be regarded as an enhancement rather than a bug.

Try making it dump an integer that has been stringified. (As James
points out elsewhere in this thread).

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-02-24T00:25:00Z

From @iabyn

On Wed, Feb 20, 2013 at 03:03:44AM +0100, demerphq wrote:

On 24 February 2010 15:20, Dave Mitchell <davem@iabyn.com> wrote:

On Mon, Feb 15, 2010 at 05:32:59PM +0100, demerphq wrote:
[snip various stuff about useqq etc ]

Assming that the bug in pp_pow gets fixed, then the only issue with
Data::Dumper is that it unnecessarily quotes NVs:

$ p -MData::Dumper -e'print Dumper 1, 2.2'
$VAR1 = 1;
$VAR2 = '2.2';

which presumably could be regarded as an enhancement rather than a bug.

Try making it dump an integer that has been stringified. (As James
points out elsewhere in this thread).

I don't follow. Surely if a string has just one of the IOK, NOK, POK flags
set, then dump it in that native format? Data Dumper seems to be
inconsistent between its handling of just IOK and just NOK.

--
The optimist believes that he lives in the best of all possible worlds.
As does the pessimist.

p5pRT · 2013-02-24T05:47:36Z

From @demerphq

On 24 February 2013 01:24, Dave Mitchell <davem@iabyn.com> wrote:

On Wed, Feb 20, 2013 at 03:03:44AM +0100, demerphq wrote:

On 24 February 2010 15:20, Dave Mitchell <davem@iabyn.com> wrote:

On Mon, Feb 15, 2010 at 05:32:59PM +0100, demerphq wrote:
[snip various stuff about useqq etc ]

Assming that the bug in pp_pow gets fixed, then the only issue with
Data::Dumper is that it unnecessarily quotes NVs:

$ p -MData::Dumper -e'print Dumper 1, 2.2'
$VAR1 = 1;
$VAR2 = '2.2';

which presumably could be regarded as an enhancement rather than a bug.

Try making it dump an integer that has been stringified. (As James
points out elsewhere in this thread).

I don't follow. Surely if a string has just one of the IOK, NOK, POK flags
set, then dump it in that native format? Data Dumper seems to be
inconsistent between its handling of just IOK and just NOK.

$ perl -MDevel::Peek -e'my $i= 0; Dump($i); print "$i"; Dump($i);'
SV = IV(0x1500b70) at 0x1500b78
REFCNT = 1
FLAGS = (PADMY,IOK,pIOK)
IV = 0
SV = PVIV(0x14edc60) at 0x1500b78
REFCNT = 1
FLAGS = (PADMY,IOK,POK,pIOK,pPOK)
IV = 0
PV = 0x14f2c30 "0"\0
CUR = 1
LEN = 8

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-02-24T12:39:48Z

From @iabyn

On Sun, Feb 24, 2013 at 06:47:05AM +0100, demerphq wrote:

On 24 February 2013 01:24, Dave Mitchell <davem@iabyn.com> wrote:

On Wed, Feb 20, 2013 at 03:03:44AM +0100, demerphq wrote:

On 24 February 2010 15:20, Dave Mitchell <davem@iabyn.com> wrote:

On Mon, Feb 15, 2010 at 05:32:59PM +0100, demerphq wrote:
[snip various stuff about useqq etc ]

Assming that the bug in pp_pow gets fixed, then the only issue with
Data::Dumper is that it unnecessarily quotes NVs:

$ p -MData::Dumper -e'print Dumper 1, 2.2'
$VAR1 = 1;
$VAR2 = '2.2';

which presumably could be regarded as an enhancement rather than a bug.

Try making it dump an integer that has been stringified. (As James
points out elsewhere in this thread).

I don't follow. Surely if a string has just one of the IOK, NOK, POK flags
set, then dump it in that native format? Data Dumper seems to be
inconsistent between its handling of just IOK and just NOK.

$ perl -MDevel::Peek -e'my $i= 0; Dump($i); print "$i"; Dump($i);'
SV = IV(0x1500b70) at 0x1500b78
REFCNT = 1
FLAGS = (PADMY,IOK,pIOK)
IV = 0
SV = PVIV(0x14edc60) at 0x1500b78
REFCNT = 1
FLAGS = (PADMY,IOK,POK,pIOK,pPOK)
IV = 0
PV = 0x14f2c30 "0"\0
CUR = 1
LEN = 8

But my point is what to do with a number that *hasn't* been stringified.
In this case, I see no reason to put quotes round the output: while
Data::Dumper inconsistently does so for NVs but not IV's, as I showed
earlier:

$ p -MData::Dumper -e'print Dumper 1, 2.2'
$VAR1 = 1;
$VAR2 = '2.2';

Do you regard that output as best and consistent? And if not, how would
you suggest it change? Personally I think it should output:

$VAR1 = 1;
$VAR2 = 2.2;

If on the other hand the vars happen to have been stringified in the
meantime, then I have no particular opinion as to how they should be
rendered (i.e. that isn't the use case that I'm arguing about).

--
O Unicef Clearasil!
Gibberish and Drivel!
-- "Bored of the Rings"

p5pRT · 2013-02-24T14:19:35Z

From @demerphq

On 24 February 2013 13:39, Dave Mitchell <davem@iabyn.com> wrote:

On Sun, Feb 24, 2013 at 06:47:05AM +0100, demerphq wrote:

On 24 February 2013 01:24, Dave Mitchell <davem@iabyn.com> wrote:

On Wed, Feb 20, 2013 at 03:03:44AM +0100, demerphq wrote:

On 24 February 2010 15:20, Dave Mitchell <davem@iabyn.com> wrote:

On Mon, Feb 15, 2010 at 05:32:59PM +0100, demerphq wrote:
[snip various stuff about useqq etc ]

Assming that the bug in pp_pow gets fixed, then the only issue with
Data::Dumper is that it unnecessarily quotes NVs:

$ p -MData::Dumper -e'print Dumper 1, 2.2'
$VAR1 = 1;
$VAR2 = '2.2';

which presumably could be regarded as an enhancement rather than a bug.

Try making it dump an integer that has been stringified. (As James
points out elsewhere in this thread).

I don't follow. Surely if a string has just one of the IOK, NOK, POK flags
set, then dump it in that native format? Data Dumper seems to be
inconsistent between its handling of just IOK and just NOK.

$ perl -MDevel::Peek -e'my $i= 0; Dump($i); print "$i"; Dump($i);'
SV = IV(0x1500b70) at 0x1500b78
REFCNT = 1
FLAGS = (PADMY,IOK,pIOK)
IV = 0
SV = PVIV(0x14edc60) at 0x1500b78
REFCNT = 1
FLAGS = (PADMY,IOK,POK,pIOK,pPOK)
IV = 0
PV = 0x14f2c30 "0"\0
CUR = 1
LEN = 8

But my point is what to do with a number that *hasn't* been stringified.
In this case, I see no reason to put quotes round the output: while
Data::Dumper inconsistently does so for NVs but not IV's, as I showed
earlier:
$ p \-MData&#8203;::Dumper \-e'print Dumper 1\, 2\.2'
$VAR1 = 1;
$VAR2 = '2\.2';
Do you regard that output as best and consistent? And if not, how would
you suggest it change? Personally I think it should output:
$VAR1 = 1;
$VAR2 = 2\.2;
If on the other hand the vars happen to have been stringified in the
meantime, then I have no particular opinion as to how they should be
rendered (i.e. that isn't the use case that I'm arguing about).

The only reason that I can think that someone might do this
deliberately would be values like Inf or other weirdo NV's that might
require quotes to round trip. I can't say if that makes sense tho...

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT added Severity Low distro-Linux labels Oct 18, 2019

jkeenan added dist-Data-Dumper issues in the dual-life blead-first Data-Dumper distribution and removed Severity Low distro-Linux labels Jul 5, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Inconsistency in Data::Dumper integer representations #10174

Inconsistency in Data::Dumper integer representations #10174

p5pRT commented Feb 14, 2010

p5pRT commented Feb 14, 2010

p5pRT commented Feb 15, 2010

p5pRT commented Feb 15, 2010

p5pRT commented Feb 15, 2010

p5pRT commented Feb 15, 2010

p5pRT commented Feb 15, 2010

p5pRT commented Feb 15, 2010

p5pRT commented Feb 24, 2010

p5pRT commented Feb 24, 2010

p5pRT commented Feb 24, 2010

p5pRT commented Feb 20, 2013

p5pRT commented Feb 20, 2013

p5pRT commented Feb 24, 2013

p5pRT commented Feb 24, 2013

p5pRT commented Feb 24, 2013

p5pRT commented Feb 24, 2013

Inconsistency in Data::Dumper integer representations #10174

Inconsistency in Data::Dumper integer representations #10174

Comments

p5pRT commented Feb 14, 2010

p5pRT commented Feb 14, 2010

From @pjscott

p5pRT commented Feb 15, 2010

From @demerphq

p5pRT commented Feb 15, 2010

p5pRT commented Feb 15, 2010

From @demerphq

p5pRT commented Feb 15, 2010

From @demerphq

p5pRT commented Feb 15, 2010

From @Tux

p5pRT commented Feb 15, 2010

From @demerphq

p5pRT commented Feb 24, 2010

From @iabyn

p5pRT commented Feb 24, 2010

From @iabyn

p5pRT commented Feb 24, 2010

From @nwc10

p5pRT commented Feb 20, 2013

From @jkeenan

p5pRT commented Feb 20, 2013

From @demerphq

p5pRT commented Feb 24, 2013

From @iabyn

p5pRT commented Feb 24, 2013

From @demerphq

p5pRT commented Feb 24, 2013

From @iabyn

p5pRT commented Feb 24, 2013

From @demerphq