[31539] in Perl-Users-Digest
Perl-Users Digest, Issue: 2798 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jan 30 21:09:26 2010
Date: Sat, 30 Jan 2010 18:09:11 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 30 Jan 2010 Volume: 11 Number: 2798
Today's topics:
Re: [OT] Re: Inconsistent results from (dos)glob <ben@morrow.me.uk>
Re: [OT] Re: Inconsistent results from (dos)glob <nospam-abuse@ilyaz.org>
Re: [OT] Re: Inconsistent results from (dos)glob <ben@morrow.me.uk>
Comparing dates of yyyy-mm-dd <user@example.net>
Re: Comparing dates of yyyy-mm-dd <john@castleamber.com>
Re: Comparing dates of yyyy-mm-dd <tadmc@seesig.invalid>
Re: Comparing dates of yyyy-mm-dd <no@email.com>
Re: Comparing dates of yyyy-mm-dd <jurgenex@hotmail.com>
Re: Comparing dates of yyyy-mm-dd <jurgenex@hotmail.com>
Operator precedence with return and if/unless (Jens Thoms Toerring)
Re: Operator precedence with return and if/unless <uri@StemSystems.com>
Re: Operator precedence with return and if/unless <ben@morrow.me.uk>
Re: steps <tadmc@seesig.invalid>
Re: What are the minimum and maximum float numbers and sln@netherlands.com
Re: What are the minimum and maximum float numbers and <pgp@doc.ic.ac.uk>
Re: What are the minimum and maximum float numbers and <hjp-usenet2@hjp.at>
Re: What are the minimum and maximum float numbers and <hjp-usenet2@hjp.at>
Re: What are the minimum and maximum float numbers and <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 30 Jan 2010 18:27:29 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] Re: Inconsistent results from (dos)glob
Message-Id: <h9ae37-vop1.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2010-01-30, Ben Morrow <ben@morrow.me.uk> wrote:
>
> > existing Perl programs that expect @ARGV to contain bytes in the current
> > code page will be broken.
>
> Perl strings contain characters, not bytes. Hence
Not true:
my $characters = "123";
my $bytes = Encode::encode ISO8859_1 => $characters;
Since perl doesn't actually maintain the distinction itself (at least as
things are currently interpreted) you could argue that $bytes contains
'characters that can be interpreted as representing the equivalent
bytes' or some such, but the fact remains that it is common in perl for
a string to contain bytes representing characters in some encoding other
than the internal one. Any data you read from a :raw filehandle, for
instance.
> a) such programs are already broken; there is no need to support
> such programs in the default configuration.
> $ENV{PERL_ARGV_IN_CP} and -Margv_in_cp should be enough to handle this.
>
> b) More often then not, Perl programs which did not work before
> would "magically start working". This is in itself an incentive...
These are both possibly true. I don't know enough about what Jan is
worried about breaking to comment.
Ben
------------------------------
Date: Sun, 31 Jan 2010 00:08:25 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: [OT] Re: Inconsistent results from (dos)glob
Message-Id: <slrnhm9ifo.i5i.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-01-30, Ben Morrow <ben@morrow.me.uk> wrote:
>> Perl strings contain characters, not bytes. Hence
> Not true:
...
> you could argue that $bytes contains
> 'characters that can be interpreted as representing the equivalent
> bytes'
Sure.
> the fact remains that it is common in perl for
> a string to contain bytes representing characters in some encoding other
> than the internal one. Any data you read from a :raw filehandle, for
> instance.
And, in these situations, one should be ready to handle them "specially".
This is why I wrote the following:
>> a) such programs are already broken; there is no need to support
>> such programs in the default configuration.
>> $ENV{PERL_ARGV_IN_CP} and -Margv_in_cp should be enough to handle this.
Yours,
Ilya
------------------------------
Date: Sun, 31 Jan 2010 01:06:02 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] Re: Inconsistent results from (dos)glob
Message-Id: <qk1f37-4o52.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2010-01-30, Ben Morrow <ben@morrow.me.uk> wrote:
>
> > the fact remains that it is common in perl for
> > a string to contain bytes representing characters in some encoding other
> > than the internal one. Any data you read from a :raw filehandle, for
> > instance.
>
> And, in these situations, one should be ready to handle them "specially".
> This is why I wrote the following:
>
> >> a) such programs are already broken; there is no need to support
> >> such programs in the default configuration.
> >> $ENV{PERL_ARGV_IN_CP} and -Margv_in_cp should be enough to handle this.
I disagree. It's not usual for perl to 'decode' data that comes in from
the outside world until you ask it to. (Apart from anything else, it's
not necessarily a lossless operation.) If you want your @ARGV decoded
from the current codepage, use
@ARGV = map Encode::decode($cp, $_), @ARGV;
(determining the correct value for $cp is left as a exercise for those
who actually care about Win32). This is exactly the same as the
situation on Unix: if your @ARGV should be interpreted according to the
current LC_CTYPE locale, you have to decode it yourself.
Ben
------------------------------
Date: Sat, 30 Jan 2010 14:00:52 -0500
From: monkeys paw <user@example.net>
Subject: Comparing dates of yyyy-mm-dd
Message-Id: <eYKdnTEHY7t2HPnWnZ2dnUVZ_sGdnZ2d@insightbb.com>
$x = '2010-01-30';
$y = '2010-01-11';
if ($y >= $x) {
print 'yes';
} else {
print 'no';
}
This prints "yes". So what is the proper
compare to show which date is "later"?
------------------------------
Date: Sat, 30 Jan 2010 13:19:50 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: Comparing dates of yyyy-mm-dd
Message-Id: <87eil7v1rd.fsf@castleamber.com>
monkeys paw <user@example.net> writes:
> $x = '2010-01-30';
> $y = '2010-01-11';
>
> if ($y >= $x) {
> print 'yes';
> } else {
> print 'no';
> }
>
> This prints "yes". So what is the proper
> compare to show which date is "later"?
string comparison, since the date format you use results in strings that
when sorted in string order follow the same order as the actual dates.
if ( $y ge $x ) { ...
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Sat, 30 Jan 2010 14:20:36 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Comparing dates of yyyy-mm-dd
Message-Id: <slrnhm94u2.e7n.tadmc@tadbox.sbcglobal.net>
monkeys paw <user@example.net> wrote:
> $x = '2010-01-30';
> $y = '2010-01-11';
You should always enable strictures in Perl programs:
use strict;
then
my $x = '2010-01-30';
my $y = '2010-01-11';
> if ($y >= $x) {
You should always enable warnings when developing Perl code:
use warnings;
If you had been using 'warnings', this would have generated a warning and
you would have found the problem easily.
Have you seen the Posting Guidelines that are posted here frequently?
> print 'yes';
You should indent code blocks.
> } else {
You should not cuddle else's.
perldoc perlstyle
> print 'no';
> }
>
> This prints "yes". So what is the proper
> compare to show which date is "later"?
You are representing dates as strings, so you should use a comparison
operator that operates on strings rather than one that operates on numbers:
if ($y ge $x) {
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
Date: Sat, 30 Jan 2010 22:05:43 +0000
From: Brian Wakem <no@email.com>
Subject: Re: Comparing dates of yyyy-mm-dd
Message-Id: <7sjopnFrvcU1@mid.individual.net>
monkeys paw wrote:
> $x = '2010-01-30';
> $y = '2010-01-11';
>
> if ($y >= $x) {
> print 'yes';
> } else {
> print 'no';
> }
>
> This prints "yes". So what is the proper
> compare to show which date is "later"?
Remove the hyphens and try again.
--
Brian Wakem
------------------------------
Date: Sat, 30 Jan 2010 14:09:24 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Comparing dates of yyyy-mm-dd
Message-Id: <0bb9m5l3nuitnunjb4if3ul7mf1g8seb3b@4ax.com>
monkeys paw <user@example.net> wrote:
>$x = '2010-01-30';
>$y = '2010-01-11';
>
>if ($y >= $x) {
>print 'yes';
>} else {
>print 'no';
>}
>
>This prints "yes".
That is to be expected, because both strings have a numerical value of
2010.
Had you used warnings then perl would have told you already.
>So what is the proper
>compare to show which date is "later"?
When you want to compare strings you should use an operator that
compares strings, in this case 'ge'.
jue
------------------------------
Date: Sat, 30 Jan 2010 15:26:26 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Comparing dates of yyyy-mm-dd
Message-Id: <0vf9m55b9ls384tou82fjn4l4vj9s31atl@4ax.com>
Brian Wakem <no@email.com> wrote:
>monkeys paw wrote:
>
>> $x = '2010-01-30';
>> $y = '2010-01-11';
>>
>> if ($y >= $x) {
>> print 'yes';
>> } else {
>> print 'no';
>> }
>>
>> This prints "yes". So what is the proper
>> compare to show which date is "later"?
>
>
>Remove the hyphens and try again.
That is certainly a highlight for the TIMTOWTDI hit list.
Very, hmmmm, shall we say "creative" approach.
jue
------------------------------
Date: 31 Jan 2010 00:06:42 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Operator precedence with return and if/unless
Message-Id: <7sjvsiFt2uU1@mid.uni-berlin.de>
Hi,
after gotten bitten by it (again) I wonder once more if
there are good reasons why in
perl -e 'sub x { return 1 and 0 } print x() . "\n";'
the 'return' seems to have a higher "precedence" than the
'and' operator, i.e. () returns 1, while for
perl -e 'sub x { return 1 && 0 } print x() . "\n";'
0 is returned. On the other hand with
perl -e 'print "bla\n" if 1 and 0;'
perl -e 'print "bla\n" if 1 && 0;'
'if' (and 'unless') has a lower "precedence" then both 'and' and
'&&', thus "bla\n" isn't printed out in either case. And the same
holds, of course, for the 'or' and '||' operators...
That doesn't look too logical or intuitive to me, so is there a
reason for that I'm missing to see or is it for some historical
reasons? Is there anything that could happen after a 'return',
so is 'return 1' an expression that has a value that could be
'and'ed with something following it?
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Sat, 30 Jan 2010 19:39:40 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Operator precedence with return and if/unless
Message-Id: <87zl3v3y5v.fsf@quad.sysarch.com>
>>>>> "JTT" == Jens Thoms Toerring <jt@toerring.de> writes:
JTT> there are good reasons why in
JTT> perl -e 'sub x { return 1 and 0 } print x() . "\n";'
JTT> the 'return' seems to have a higher "precedence" than the
JTT> 'and' operator, i.e. () returns 1, while for
JTT> perl -e 'sub x { return 1 && 0 } print x() . "\n";'
JTT> 0 is returned. On the other hand with
JTT> perl -e 'print "bla\n" if 1 and 0;'
JTT> perl -e 'print "bla\n" if 1 && 0;'
JTT> 'if' (and 'unless') has a lower "precedence" then both 'and' and
JTT> '&&', thus "bla\n" isn't printed out in either case. And the same
JTT> holds, of course, for the 'or' and '||' operators...
'and' and '&&' do the exact same operation. the ONLY difference is
precedence. this is true for all the boolean ops which have symbolic and
spelled out names. the spelled out names were added to perl5 later. they
were made lower precedence on purpose so you could do boolean ops which
bind lower than things such as assignment, func calls, etc.
JTT> That doesn't look too logical or intuitive to me, so is there a
JTT> reason for that I'm missing to see or is it for some historical
JTT> reasons? Is there anything that could happen after a 'return', so
JTT> is 'return 1' an expression that has a value that could be
JTT> 'and'ed with something following it?
the reason they are there is so you can have a CHOICE in precedence. it
allows for different syntax and some like it one way or the other.
look at these two common lines:
open( my $foo, $file ) || die "can't open $file $!" ;
open my $foo, $file or die "can't open $file $!" ;
the 'or' allows you to drop the () on the open call.
a good rule (courtesy of peter scott) about when to use which form is:
use the symbolic forms (||, &&, !) when doing a boolean expression
use the spelled forms( or, and, not) when doing flow control
the precedence levels work best in those situations.
$foo = $bar and last ;
$foo = $bar || $default ;
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Sun, 31 Jan 2010 00:58:26 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Operator precedence with return and if/unless
Message-Id: <i61f37-4o52.ln1@osiris.mauzo.dyndns.org>
Quoth jt@toerring.de (Jens Thoms Toerring):
>
> after gotten bitten by it (again) I wonder once more if
> there are good reasons why in
>
> perl -e 'sub x { return 1 and 0 } print x() . "\n";'
>
> the 'return' seems to have a higher "precedence" than the
> 'and' operator, i.e. () returns 1, while for
>
> perl -e 'sub x { return 1 && 0 } print x() . "\n";'
>
> 0 is returned. On the other hand with
>
> perl -e 'print "bla\n" if 1 and 0;'
> perl -e 'print "bla\n" if 1 && 0;'
>
> 'if' (and 'unless') has a lower "precedence" then both 'and' and
> '&&', thus "bla\n" isn't printed out in either case. And the same
> holds, of course, for the 'or' and '||' operators...
>
> That doesn't look too logical or intuitive to me, so is there a
> reason for that I'm missing to see or is it for some historical
> reasons? Is there anything that could happen after a 'return',
> so is 'return 1' an expression that has a value that could be
> 'and'ed with something following it?
'return' parses as a listop, so for consistency it should behave like
'print' rather than like 'if'. You might as well ask why 'exit' or 'die'
(or indeed POSIX::_exit) also behave the same way.
Ben
------------------------------
Date: Sat, 30 Jan 2010 08:55:03 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: steps
Message-Id: <slrnhm8hrl.dos.tadmc@tadbox.sbcglobal.net>
Robin <robin1@cnsp.com> wrote:
> Subject: steps
Please put the subject of your article in the Subject of your article.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
Date: Sat, 30 Jan 2010 07:26:54 -0800
From: sln@netherlands.com
Subject: Re: What are the minimum and maximum float numbers and integers?
Message-Id: <5qh8m5dlp3ti641vav62qg81jb18hjsdj1@4ax.com>
On Sat, 30 Jan 2010 11:44:11 +0100, "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>On 2010-01-30 00:07, sln@netherlands.com <sln@netherlands.com> wrote:
>> I don't know why division by 2 should be any different than >>1.
>
>Because division is always done in floating point arithmetic in Perl.
Doh, what was I thinking. Of course.
>So the result of (18446744073709551615/2) should be
>9223372036854775807.5 - but that isn't representable in a 53 bit
>mantissa, so it is rounded to the next representable value which happens
>to be 9223372036854775808 (the next lower representable FP value btw is
>9223372036854774784, so subtracting any value <= 512 doesn't have any
>effect).
In C, the value passed to printf using formatter %d must be an integer (signed or not).
So the result of the division, a float, must be coerced to integer:
printf ("%d", (int)(18446744073709551615/2) );
Does Perl do this coersion in C or does it do its own rounding then chopping via
custom methods?
I guess the IEEE 87 standard is 53 bit mantissa so it can't handle a 64 bit
(-1) u_integer division, but would handle 32 bit u_integers. That explains
how printf ("%d", 4294967295/2); works, but how can the previous poster's
64 bit result be -9223372036854775808 which is almost correct?
If his Perl is using long-double shouldn't this extend the mantissa past 53 bits?
As an aside, I wonder if Perl is sometimes compiled to take advantage of
faster SSE-2 64-bit in lieu of precision 80 bit. I know when I compile C++
I don't enable support for those instructions, and usually select precision
over speed.
Also, I thought cpu's do integer arithmetic +-/*
Thanks.
-sln
------------------------------
Date: Sat, 30 Jan 2010 16:43:25 +0000
From: Philip Potter <pgp@doc.ic.ac.uk>
Subject: Re: What are the minimum and maximum float numbers and integers?
Message-Id: <hk1njc$m54$1@speranza.aioe.org>
On 30/01/2010 10:44, Peter J. Holzer wrote:
> C doesn't define[1] what happens if you right-shift a negative value.
>
> But Perl does, at least if don't "use integer":
>
> | Note that both "<<" and ">>" in Perl are implemented directly using
> | "<<" and ">>" in C. If "use integer" (see "Integer Arithmetic") is in
> | force then signed C integers are used, else unsigned C integers are
> | used.
> (perldoc perlop)
>
> So (-1 >> 1) uses unsigned integer operations. (unsigned)-1 is
> guaranteed to be the largest unsigned integer, so (-1 >> 1) is half of
> that which is half the largest signed integer (unless there are unused
> bits in the implementation, which C allows, but that's exceedingly
> rare).
Even if there are padding bits, the C Standard defines the unsigned
right-shift E1 >> E2 as the integral part of E1 / (2**E2). The result
must be a valid unsigned integer. As a result, padding bits cannot
change the meaning of a bitshift operation.
Phil
------------------------------
Date: Sat, 30 Jan 2010 22:52:19 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: What are the minimum and maximum float numbers and integers?
Message-Id: <slrnhm9agk.dfr.hjp-usenet2@hrunkner.hjp.at>
On 2010-01-30 16:43, Philip Potter <pgp@doc.ic.ac.uk> wrote:
> On 30/01/2010 10:44, Peter J. Holzer wrote:
>> C doesn't define[1] what happens if you right-shift a negative value.
>>
>> But Perl does, at least if don't "use integer":
>>
>> | Note that both "<<" and ">>" in Perl are implemented directly using
>> | "<<" and ">>" in C. If "use integer" (see "Integer Arithmetic") is in
>> | force then signed C integers are used, else unsigned C integers are
>> | used.
>> (perldoc perlop)
>>
>> So (-1 >> 1) uses unsigned integer operations. (unsigned)-1 is
>> guaranteed to be the largest unsigned integer, so (-1 >> 1) is half of
>> that which is half the largest signed integer (unless there are unused
>> bits in the implementation, which C allows, but that's exceedingly
>> rare).
>
> Even if there are padding bits, the C Standard defines the unsigned
> right-shift E1 >> E2 as the integral part of E1 / (2**E2). The result
> must be a valid unsigned integer.
Yes but not necessarily a valid signed integer. More specifically
UINT_MAX / 2 == INT_MAX
doesn't have to be true. An unsigned int may use more or less bits for
representing the value than a signed int.
> As a result, padding bits cannot change the meaning of a bitshift
> operation.
This isn't about the meaning but about the result. UINT_MAX >> 2 is
always the same as UINT_MAX / 2, but this is not necessarily the same as
INT_MAX.
hp
------------------------------
Date: Sat, 30 Jan 2010 23:24:50 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: What are the minimum and maximum float numbers and integers?
Message-Id: <slrnhm9cdk.dfr.hjp-usenet2@hrunkner.hjp.at>
On 2010-01-30 15:26, sln@netherlands.com <sln@netherlands.com> wrote:
> On Sat, 30 Jan 2010 11:44:11 +0100, "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>>On 2010-01-30 00:07, sln@netherlands.com <sln@netherlands.com> wrote:
>>> I don't know why division by 2 should be any different than >>1.
>>
>>Because division is always done in floating point arithmetic in Perl.
>
> Doh, what was I thinking. Of course.
>
>
>>So the result of (18446744073709551615/2) should be
>>9223372036854775807.5 - but that isn't representable in a 53 bit
>>mantissa, so it is rounded to the next representable value which happens
>>to be 9223372036854775808 (the next lower representable FP value btw is
>>9223372036854774784, so subtracting any value <= 512 doesn't have any
>>effect).
>
> In C, the value passed to printf using formatter %d must be an integer (signed or not).
> So the result of the division, a float, must be coerced to integer:
> printf ("%d", (int)(18446744073709551615/2) );
> Does Perl do this coersion in C or does it do its own rounding then chopping via
> custom methods?
Since perl is written in C, it obviously does it "in C", but how exactly
the conversion is done I don't know (and I'm currently too lazy to check
the source). My guess is that it is a simple cast to unsigned int:
printf "%d\n", 1E100
prints -1 on my systems which is the same as
printf("%d\n", (unsigned int)1E100);
in C. Since this result is arguably wrong I wouldn't rely on it -
somebody might someday fix it.
> I guess the IEEE 87 standard is 53 bit mantissa so it can't handle a 64 bit
> (-1) u_integer division, but would handle 32 bit u_integers. That explains
> how printf ("%d", 4294967295/2); works, but how can the previous poster's
> 64 bit result be -9223372036854775808 which is almost correct?
I think I explained that. What wasn't clear about the explanation?
> As an aside, I wonder if Perl is sometimes compiled to take advantage of
> faster SSE-2 64-bit in lieu of precision 80 bit.
The gcc manual says about SSE instructions:
| For the x86-64 compiler, these extensions are enabled by default.
So, it you are using perl on a 64 bit Linux system, it will (almost
certainly) use SSE instructions. The speed advantage is probably small -
interpreter overhead is likely to be much greater than the time actually
spent in FP arithmetic.
> Also, I thought cpu's do integer arithmetic +-/*
CPUs do what they are told.
hp
------------------------------
Date: Sat, 30 Jan 2010 23:19:29 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: What are the minimum and maximum float numbers and integers?
Message-Id: <1dre37-ac52.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2010-01-30 15:26, sln@netherlands.com <sln@netherlands.com> wrote:
> >
> > Does Perl do this coersion in C or does it do its own rounding then
> chopping via
> > custom methods?
>
> Since perl is written in C, it obviously does it "in C", but how exactly
> the conversion is done I don't know (and I'm currently too lazy to check
> the source). My guess is that it is a simple cast to unsigned int:
>
> printf "%d\n", 1E100
>
> prints -1 on my systems which is the same as
>
> printf("%d\n", (unsigned int)1E100);
>
> in C. Since this result is arguably wrong I wouldn't rely on it -
> somebody might someday fix it.
Perl calls SvIV (or SvUV for %u) which is the normal make-this-scalar-a-
signed-int operation. AFAICT it does this first for all of %d, %hd, %sd,
%ld and %qd, followed by casting to the appropriate C type, so if your
perl is build with 32-bit IVs you can't print a float greater than 2^31
using %d even if Configure found a 64-bit Quad_t type.
I have to say I'm surprised that SvIV ever does overflow to -1, but it
appears it does:
~% perl -Minteger -E'say for 1E100, 0+1E100'
1e+100
-1
~%
I might consider this a bug, since it's not what C does with
(int)(1e100)
but rather what C does with
(int)(unsigned int)(1e100)
I'm not sure going NV->IV via UV is helpful in this case.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2798
***************************************
