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
unpack 'a3#a*' misbehaving #389
Comments
From ilya@math.ohio-state.edu DB<1> x unpack 'Z3#a*', pack 'Z3#a*', '123456789012345' OK. DB<2> x pack 'a3#a*', '123456789012345' OK. DB<3> x unpack 'a3#a*', pack 'a3#a*', '123456789012345' ;' called at lib/perl5db.pl line 1246 The warning is understandable, but it is only a warning! As you see, Ilya Site configuration information for perl 5.00560: Configured by ilya at Wed Aug 4 22:44:30 EDT 1999. Summary of my perl5 (revision 5.0 version 5 subversion 60) configuration: Locally applied patches: @INC for perl 5.00560: Environment for perl 5.00560: |
From [Unknown Contact. See original ticket]On Tue, 17 Aug 1999 at 03:37:30 -0400, Ilya Zakharevich wrote:
[and the unpack gets a zero figure for the length because of the I just used POPi to pick up the number, and this calls Perl_sv_2iv. This So: Am I misusing POPi [pp.c line 3399 or so], or is there a bug in And, I can't help feeling that /\d+\0+/ looks like a bona-fide number to Ian |
From [Unknown Contact. See original ticket]Ian Phillipps <ian@dial.pipex.com> writes:
\d+\0 looks _more_ like a number to me than \d+\s ! -- |
From [Unknown Contact. See original ticket]On Wed, Aug 18, 1999 at 12:47:09PM +0100, Ian Phillipps wrote:
What is/was strange to me is that POPi is used in pp_add as well, but
Aha! It is not POPi, it is POPn! > perl -Minteger -wle "$two = qq(2\0); print 2+$two" So it is *definitely* a bug in sv_2iv. Ilya |
From [Unknown Contact. See original ticket]On Wed, 18 Aug 1999 at 17:50:59 +0100, Nick Ing-Simmons wrote:
I propose this, which will make Ilya's case work OK, but doesn't fix the My patch will stop the looks_like_number scan at the first "\0", which None of the 1440 op/numconvert tests is affected by this patch :-) (My apologies if this doesn't go cleanly on to 60...) Inline Patch--- sv.c.orig Mon Aug 2 22:29:12 1999
+++ sv.c Thu Aug 19 12:31:18 1999
@@ -1635,5 +1635,5 @@
while (isSPACE(*s))
s++;
- if (s >= send)
+ if (s >= send || *s == 0)
return numtype;
if (len == 10 && memEQ(sbegin, "0 but true", 10))
Ian |
From [Unknown Contact. See original ticket]On Thu, Aug 19, 1999 at 12:56:25PM +0100, Ian Phillipps wrote:
I would prefer sv_2iv() call conversion routine after emitting a
Well, they fence a different can of worms... Ilya |
From [Unknown Contact. See original ticket]On Thu, 19 Aug 1999 at 14:32:08 -0400, Ilya Zakharevich wrote:
Ian 1> I can't help feeling that /\d+\0+/ looks like a bona-fide number to Nick > \d+\0 looks _more_ like a number to me than \d+\s ! Ian 2 > I propose this, which will make Ilya's case work OK, but doesn't fix the Ian 2 > My patch will stop the looks_like_number scan at the first "\0", which Ilya > I would prefer sv_2iv() call conversion routine after emitting a This patchlet was in support of Nick's agreement with my suggestion that Fix for sv_2iv: Unfortunately, looks_like_number has two functions: Inline Patch--- sv.c.orig Mon Aug 2 22:29:12 1999
+++ sv.c Thu Aug 19 23:26:25 1999
@@ -1156,4 +1156,11 @@
I32 numtype = looks_like_number(sv);
+ if (!numtype) {
+ dTHR;
+ if (ckWARN(WARN_NUMERIC))
+ not_a_number(sv);
+ numtype = IS_NUMBER_NOT_IV; /* Assume the worst case */
+ }
+
/* We want to avoid a possible problem when we cache an IV which
may be later translated to an NV, and the resulting NV is not
@@ -1191,5 +1198,5 @@
}
}
- else if (numtype) {
+ else {
/* The NV may be reconstructed from IV - safe to cache IV,
which may be calculated by atol(). */
@@ -1199,14 +1206,4 @@
SvIVX(sv) = Atol(SvPVX(sv));
}
- else { /* Not a number. Cache 0. */
- dTHR;
-
- if (SvTYPE(sv) < SVt_PVIV)
- sv_upgrade(sv, SVt_PVIV);
- SvIVX(sv) = 0;
- (void)SvIOK_on(sv);
- if (ckWARN(WARN_NUMERIC))
- not_a_number(sv);
- }
}
else {
@@ -1635,5 +1632,5 @@
while (isSPACE(*s))
s++;
- if (s >= send)
+ if (s >= send || *s == 0)
return numtype;
if (len == 10 && memEQ(sbegin, "0 but true", 10)) |
From [Unknown Contact. See original ticket]On Thu, Aug 19, 1999 at 11:34:32PM +0100, Ian Phillipps wrote:
I would prefer things to remain as they are. I saw no real-line Thus IMO there is no value in removing this strictness, while there is
But why this is an issue for sv_2iv() but not for sv_2nv()? I find your argument not very convincing. Ilya |
Migrated from rt.perl.org#1224 (status was 'resolved')
Searchable as RT1224$
The text was updated successfully, but these errors were encountered: