MIME-Version: | 1.0 |
X-Spam-Status: | No, score=-2.149 tagged_above=-99.9 required=10 tests=[AWL=-0.238, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham |
Content-Disposition: | inline |
X-Spam-Flag: | NO |
content-type: | text/plain; charset="utf-8" |
Message-ID: | <20150202103301.GA4367@fysh.org> |
X-Virus-Scanned: | Debian amavisd-new at bestpractical.com |
X-Spam-Score: | -2.149 |
Received: | from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 68B602400EC for <cpan-bug+Sereal-Encoder@hipster.bestpractical.com>; Mon, 2 Feb 2015 05:33:19 -0500 (EST) |
Received: | from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePqvGagsWPTs for <cpan-bug+Sereal-Encoder@hipster.bestpractical.com>; Mon, 2 Feb 2015 05:33:18 -0500 (EST) |
Received: | from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 12B2A240061 for <bug-Sereal-Encoder@rt.cpan.org>; Mon, 2 Feb 2015 05:33:17 -0500 (EST) |
Received: | (qmail 2037 invoked by alias); 2 Feb 2015 10:33:17 -0000 |
Received: | from river.fysh.org (HELO river.fysh.org) (5.135.154.127) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 02 Feb 2015 02:33:09 -0800 |
Received: | from zefram by river.fysh.org with local (Exim 4.80 #2 (Debian)) id 1YIEJR-0001mh-BJ; Mon, 02 Feb 2015 10:33:01 +0000 |
Delivered-To: | cpan-bug+Sereal-Encoder@hipster.bestpractical.com |
Subject: | losing string value of semi-numeric string |
Return-Path: | <zefram@fysh.org> |
X-RT-Mail-Extension: | sereal-encoder |
X-Original-To: | cpan-bug+Sereal-Encoder@hipster.bestpractical.com |
X-Spam-Check-BY: | la.mx.develooper.com |
Date: | Mon, 2 Feb 2015 10:33:01 +0000 |
X-Spam-Level: | |
To: | bug-Sereal-Encoder@rt.cpan.org |
From: | Zefram <zefram@fysh.org> |
X-RT-Original-Encoding: | ascii |
X-RT-Interface: | |
Content-Length: | 1315 |
$ perl -MSereal::Encoder=encode_sereal -MSereal::Decoder=decode_sereal -lwe 'print $]; print $Sereal::Encoder::VERSION; my $a="0 but true"; print decode_sereal(encode_sereal($a)); my $b = $a+0; print $a; print decode_sereal(encode_sereal($a));'
5.018002
3.005
0 but true
0 but true
0
I believe the first encoding is representing $a as a string but the
second encoding is representing it as a pure integer, based on the IOK
flag. In the case of this string, along with infinitely many others
such as "00", "01", and "1 ", the integer representation is lossy.
It's particularly significant for strings such as "0 but true" and "00"
which qualify as true but come out as false when mangled by the lossy
encoding. But even when the truth value doesn't change, it is not at
all acceptable to lose the string value.
The underlying mistake is that you've treated the IOK flag as implying
that the scalar is fully characterised by its IV. In general that is
not the case. For scalars that are both IOK and POK, to see whether
integer representation suffices you need to perform the IV->PV coercion
yourself, and see whether the PV generated from the IV matches the
scalar's actual PV. Similar remarks apply to NOK and NV. For extra fun,
the exact meaning of the [PIN]OK flags varies between Perl versions.
-zefram