This Week on perl5-porters (7-13 July 2003)

This Week on perl5-porters (7-13 July 2003)
  In a two-release-candidate-week, there are plenty of things to
  summarize. Learn what happened behind the scenes : random seeding of
  hashing, deprecation of vstrings, signals, floats, and the other things.

5.8.1-RC1 and -RC2
  As I was saying, this week, Jarkko Hietaniemi packaged *two* release
  candidates of the upcoming maintenance release of perl, 5.8.1. There
  won't be another one before two weeks, because he's on a well-deserved
  vacation now. That gives you plenty of time to test the RC2 with your
  favourite applications !

      http://www.cpan.org/authors/id/J/JH/JHI/perl-5.8.1-RC2.tar.gz

Random hash seeding and security
  At some point between the two release candidates, Jarkko decided to
  change the default setting for the hash seed randomization patch (which
  is discussed for two weeks -- see our previous episodes.) For RC1,
  hashes were randomized by default ; in other words, the hash key for a
  given string changes across executions of perl -- and with it, the order
  in which keys() returns the keys of a given hash, constructed in a given
  way. -- This is no longer true with 5.8.1-RC2, where this feature must
  be explicitly enabled, either by an environment variable, or by a
  configure-time compilation flag.

  Chip Salzenberg, Tels, and other members of the crew expressed
  disapproval and think that randomization (that benefits to security)
  should be the default -- arguing that only broken programs will break
  with this change anyway.

      RC2 is out : http://xrl.us/lzr

  Scott A Crosby confesses he is now analysing worst cases of regular
  expression matching.

      http://xrl.us/lzs

vstrings RIP
  Version strings (a.k.a. vstrings) are now Officially Deprecated in perl
  5.8.1. They will be removed in perl 5.10.0. This is apparently the
  result of an anti-vstring cabal, lead by Casey West and other
  influential people, at OSCON.

      vstrings must die! - http://xrl.us/lzt

  There is another welcomed change in vstrings behaviour for 5.8.1 : the
  vstrings that begin with a "v" and that don't contain dots now get
  autoquoted by "=>", thanks to John Peacock. That means that the
  following hash :

      %h = ( v65 => 1 );

  contains the key "A" with perl 5.6.0 up to 5.8.0, and contains (less
  surprisingly) the key "v65" with all other perls. (The behaviour for
  vstrings that contains dots, such as 5.8.1 or "v65.66", doesn't change.
  In other words this change only affects bareword-like vstrings.)

  John posted also a roadmap to remove vstrings from bleadperl, and to
  replace them by version objects.

      http://xrl.us/lzu

5.6.1++
  Rafael Garcia-Suarez pleads for a new release in the 5.6.x branch. The
  modest goal is not to fix bugs, upgrade modules or improve docs, but
  only to enable compilation on recent systems (more precisely, with the
  gcc 3 compiler or on recent UnixWare variants -- other compilation fixes
  welcomed.) The difference with 5.6.1 being minimal (complete patch in
  the mailing list archives), Rafael suggests the version number 5.6.1a,
  buts lots of people come with lots of good arguments in favor of a
  full-fledged increment, 5.6.2.

      http://xrl.us/lzv

Sort subroutine edge cases
  The subroutine optionally used to give a sort criterion to "sort" shall
  not return an undefined value. If it does so, it produces the fatal
  error *Sort subroutine didn't return a numeric value*. Rafael (after
  Matt Sergeant) notices that an innocent-looking numerical comparison
  subroutine may throw this error, because on systems that support
  not-a-number values, the "<=>" operator returns "undef" when one of its
  operands is NaN.

  Rafael asks whether another more satisfactory behaviour can be found :
  for example, producing a warning and/or returning an empty list. But it
  was finally decided that the current behaviour was fine. In the case one
  would want to safeguard a numerical sort against NaNs, the correct way
  to do it is to filter them out beforehand :

      my @sorted = sort { $a <=> $b } grep { $_ == $_ } @unsorted ;

      http://xrl.us/lzw

Safe and unsafe signals
  Chip Salzenberg notices that POSIX::sigaction is not using the safe (or
  *deferred*) signal mechanism. Bug or feature ? The POSIX module is
  supposed to give interfaces to the C-level routines, and the C-level
  sigaction is unsafe from the point of view of Perl ; but on the other
  hand, someone who needs the features from the POSIX sigaction can't rely
  on perl-level safe signals. Chip then implemented optional safe signals
  via POSIX::sigaction, using a new "safe" flag.

      http://xrl.us/lzx

Floating point exceptions
  Paul Bostrom reported a problem with the SIGFPE signal : programs that
  are run from a perl script ignore it. That's because perl, unable to
  handle it consistently, chooses to always ignore it.

  Chip solved this with a patch that remembers the original state of the
  SIGFPE signal handler, and that temporarily sets it back to that state
  for the duration of each exec() call.

      http://xrl.us/lzy

More about floats
  Philip Newton noticed long ago that B::Deparse deparses infinite floats
  as the bareword "inf" (bug #6944). Stephen McCamant looked at it, and
  more generally, at ways to convert any bit pattern that can appear in an
  NV to a piece of Perl code to produce the same value, whether it's
  finite or infinite. He finds out that the round-trip property of perl's
  implementation of atof() is far from perfect : when a numerical value is
  printed in decimal by perl, and then parsed again into a float, the
  final value isn't (in a large number of cases) exactly the same than the
  original one, due to rounding. Yitzchak Scott-Thoennes suggests that
  B::Deparse could emit pack/unpack code instead, but in fact an
  exponent/mantissa decomposition should be enough.

      http://xrl.us/lzz

In Brief
  Stas Bekman asks for an API to set the hash seed internally before the
  interpreter is started, to be used by mod_perl 2. As of this writing,
  mod_perl 2 can't be built against the release candidates.

  Using perl's malloc() on FreeBSD produce spurious failures in the
  threading stress tests. Consequently, Jarkko reverted perl to use
  FreeBSD's malloc(), in spite of its slowness (see Dan Kogai's analysis
  in last week summary.)

  Randal L. Schwartz and Michael Schwern apparently came to a conclusion
  regarding the "UNINST=1" feature of ExtUtils::MakeMaker : its behaviour
  will not change, and the problems it causes, notably by conflicting with
  the version of "base.pm" that lives on CPAN, will be worked around for
  now.

      http://xrl.us/lz2

  Claes Jacobsson finds that attribute handlers are apparently not invoked
  from within an "eval(STRING)".

      http://xrl.us/lz3

  Ken Williams released File::Spec 0.84 on CPAN (and is going the maintain
  it). It's in sync with the version currently in bleadperl and maintperl.

About this summary
  I began to work on those weekly summaries exactly one year ago.

  To celebrate this anniversary, I want a Ponie !
0
rgarciasuarez
7/14/2003 8:27:29 AM
perl.perl5.porters 47902 articles. 1 followers. Follow

6 Replies
190 Views

Similar Articles

[PageSpeed] 53

=2D----BEGIN PGP SIGNED MESSAGE-----

Rafael Garcia-Suarez <rgarciasuarez@free.fr> wrote:

>Sort subroutine edge cases
>  The subroutine optionally used to give a sort criterion to "sort" shall
>  not return an undefined value. If it does so, it produces the fatal
>  error *Sort subroutine didn't return a numeric value*. Rafael (after
>  Matt Sergeant) notices that an innocent-looking numerical comparison
>  subroutine may throw this error, because on systems that support

>      my @sorted =3D sort { $a <=3D> $b } grep { $_ =3D=3D $_ } @unsorted ;
>
>     http://xrl.us/lzw

Interesting to note is that this doesn't work under bignum as expected=20
(expected is that there is no difference):

	> cat test.pl
	#!/usr/bin/perl -w
	push @unsorted, $_ for (3..1, 0+NaaN);
	@sorted =3D sort { $a <=3D> $b } grep { $_ =3D=3D $_ } @unsorted ;
	print join("\n",@sorted);
	> perl -w test.pl
	Argument "NaaN" isn't numeric in addition (+) at test.pl line 3.
	0
	1
	2
	3
	> perl -Mbignum -w test.pl
	Use of uninitialized value in numeric eq (=3D=3D) at test.pl line 5.
	Use of uninitialized value in sort at test.pl line 5.
	1
	2
	3
	NaN

The reason is that although <=3D> returns undef,  =3D=3D returns 1 because =
both of=20
the NaN are considered equal. I guess this counts as a BigInt bug?

Best wishes,

Tels
 =20
=2D --=20
 Signed on Mon Jul 14 20:24:17 2003 with key 0x93B84C15.
 PGP key on http://bloodgate.com/tels.asc or per email.

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

iQEVAwUBPxL1pHcLPEOTuEwVAQH8cgf/QgPOTCIU9CVAIpx4I2RcqfsKqaZlwhMm
YFwMgNuFmnOO2wkLwrRYCRnkQO95VDzZ1e6oizMtpo76ONSw7SL2Y4qDHA54n/db
b5KSNHGzLYZlYiNsSiC4TFXnfCklde07sdZZ0r31U7n/GnDO/YGHKi/Sd9q/Si6t
rflnni+47fuE1uX8QXJIrwk0m0TWUD/hE+ms87vsJRmdU0CO0j4pT4nhjirbB+Tw
E3Xfr5/u/f2qB23k1Q5gpp3huDOAfNif/89cqsX6bhA/q2KpFLF8hPQ/FUmVsluI
ljpbwnT9G5qXyuMm5218Ly/7CeB+UgQuVfzDSYhJpVeuNagoldobUg=3D=3D
=3DrozO
=2D----END PGP SIGNATURE-----

0
perl_dummy
7/14/2003 6:25:39 PM
On Jul 14, Tels wrote:
> . . . . although <=> returns undef,  == returns 1 because both of 
> the NaN are considered equal. I guess this counts as a BigInt bug?

    Absolutely.  NaN != $x, for *all* $x.

    - Kurt

0
kstar
7/14/2003 7:43:37 PM
>   Claes Jacobsson finds that attribute handlers are apparently not 
> invoked
>   from within an "eval(STRING)".

They are invoked, but the symbol passed to the attribute handler from 
eval("sub foo : MyAttr {}") is anonymous and not a GLOB ref.

/claes

0
claes
7/14/2003 9:05:52 PM
Tels <perl_dummy@bloodgate.com> wrote:
:Rafael Garcia-Suarez <rgarciasuarez@free.fr> wrote:
:>Sort subroutine edge cases
[...]
:>      my @sorted = sort { $a <=> $b } grep { $_ == $_ } @unsorted ;
:
:Interesting to note is that this doesn't work under bignum as expected 
:(expected is that there is no difference):
:
:	> cat test.pl
:	#!/usr/bin/perl -w
:	push @unsorted, $_ for (3..1, 0+NaaN);

Note that C< 3..1 > gives an empty list - I guess your real code has
C< 1..3 >. Also, C< 0+NaaN > under normal perl gives 0, not NaN, so
this doesn't actually show anything to do with the NaN discussion.

:	@sorted = sort { $a <=> $b } grep { $_ == $_ } @unsorted ;
:	print join("\n",@sorted);
:	> perl -w test.pl
:	Argument "NaaN" isn't numeric in addition (+) at test.pl line 3.
:	0
:	1
:	2
:	3

Note that 0 is printed: had it been a NaN, it would have been removed
by the grep(). You can see this by changing C< 0+NaaN > to, for example,
C< 0e999 >.

:	> perl -Mbignum -w test.pl
:	Use of uninitialized value in numeric eq (==) at test.pl line 5.
:	Use of uninitialized value in sort at test.pl line 5.
:	1
:	2
:	3
:	NaN
:
:The reason is that although <=> returns undef,  == returns 1 because both of 
:the NaN are considered equal. I guess this counts as a BigInt bug?

Or possibly two bugs: I'm not sure why C<< 0+NaaN >> is giving NaN rather
than (a warning, then) zero.

Or maybe three: bignum gives some rather strange results for C< 0e999 >.
Of course it also seems strange that perl itself gives NaN for that
rather than zero.

Hugo
0
hv
7/14/2003 9:25:18 PM
=2D----BEGIN PGP SIGNED MESSAGE-----

Moin,

On Monday 14 July 2003 23:25, you wrote:
> Tels <perl_dummy@bloodgate.com> wrote:
> :Rafael Garcia-Suarez <rgarciasuarez@free.fr> wrote:
> :>Sort subroutine edge cases
>
> [...]
>
> :>      my @sorted =3D sort { $a <=3D> $b } grep { $_ =3D=3D $_ } @unsort=
ed ;
> :
> :Interesting to note is that this doesn't work under bignum as expected
> :
> :(expected is that there is no difference):
> :	> cat test.pl
> :
> :	#!/usr/bin/perl -w
> :	push @unsorted, $_ for (3..1, 0+NaaN);
>
> Note that C< 3..1 > gives an empty list - I guess your real code has
> C< 1..3 >.=20

Yes, it has. Sorry about that cypo.=20

> Also, C< 0+NaaN > under normal perl gives 0, not NaN, so
> this doesn't actually show anything to do with the NaN discussion.

Actually, I wondered how to generate a NaN in Perl.

However, my example also showed that Perl and bignum differ, which they=20
shouldn't, NaN or not.

> :	@sorted =3D sort { $a <=3D> $b } grep { $_ =3D=3D $_ } @unsorted ;
> :	print join("\n",@sorted);
> :
> :	> perl -w test.pl
> :
> :	Argument "NaaN" isn't numeric in addition (+) at test.pl line 3.
> :	0
> :	1
> :	2
> :	3
>
> Note that 0 is printed: had it been a NaN, it would have been removed
> by the grep(). You can see this by changing C< 0+NaaN > to, for example,
> C< 0e999 >.

Why is 0e999 a NaN and not inf? Also, why is 0+NaaN 0, and not NaN?

(Just curios)

> :	> perl -Mbignum -w test.pl
> :
> :	Use of uninitialized value in numeric eq (=3D=3D) at test.pl line 5.
> :	Use of uninitialized value in sort at test.pl line 5.
> :	1
> :	2
> :	3
> :	NaN
> :
> :The reason is that although <=3D> returns undef,  =3D=3D returns 1 becau=
se both
> : of the NaN are considered equal. I guess this counts as a BigInt bug?
>
> Or possibly two bugs: I'm not sure why C<< 0+NaaN >> is giving NaN rather
> than (a warning, then) zero.

Because 0 becomes a bigint, and a bigint plus the string 'NaaN' results in =
NaN=20
(because "NaaN" results in a "NaN" and NaN plus anything is again a NaN).=20

te@null:~> perl -Mbignum -le 'print Math::BigInt->new("NaaN")'
NaN

> Or maybe three: bignum gives some rather strange results for C< 0e999 >.

te@null:~> perl -Mbignum -le 'print 0e999'
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
00000000000000000000000000
te@null:~>

Oh :-(

te@null:~> perl -Mbignum -le 'print Math::BigInt->new("0e12")'
00000000

Ugh!

The fix is to add this one-liner in _split() at a strategically important=20
place:

	# handle the 0e999 case here
	$ev =3D 0 if $miv eq '0' && $mfv eq '';

That seems to help. Thanx for pointing this out, I'll add it into v1.65 :)

> Of course it also seems strange that perl itself gives NaN for that
> rather than zero.

I can't comment on that, my math is rusty and relies on common sense instea=
d=20
of the official rules :)

Thanx,

Tels

=2D --=20
 Signed on Mon Jul 14 23:53:07 2003 with key 0x93B84C15.
 PGP key on http://bloodgate.com/tels.asc or per email.


=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

iQEVAwUBPxMpjHcLPEOTuEwVAQGkygf/SDb86SDrpmK3dPnqEDK2AiU/sGDRnEfH
IXoTwb51NBv174wxkKack9j9UgouGmg9V1gi71tPppNPDjM2zC9dgLVjI8com1RM
lsvPLoMuqex6ijWv51IG5fSOQb0wbBOStBvh9fXiQnQn29/ptKGJlwAMSdxIr+0A
Lyf/5nmvuzyUNhKYCUWAk2NzTG2mRuFtjThvCeh0DB7DZckSuuzAbooV5sqHPtKU
IgD64xD2A6wnZ2d66nWybp/hk4YutHTtQZnXU11YEmgAEzh3xV3/oSD8Le50CsQB
B7V9QZI4Qh6miDqlwsJWieTlU31+wS7wxlUuj3sh/IjnvOzEFp/fBw=3D=3D
=3Dgi0D
=2D----END PGP SIGNATURE-----

0
perl_dummy
7/14/2003 10:06:59 PM
perl5-porters@ton.iguana.be (Ton Hospel) wrote:
:Actually, i've often been annoyed that there is no easy way to *portably* 
:write "infinity", which is very convenient in e.g. min and max loops. I 
:usually use something like 1e9999.
:
:I understand that in 5.8 perl now has it's own "atof", so why not just
:recognize inf (or infinity) (and NaN) for them so the name is standardized
:and can be depended upon ?
:(are there still any cpu's left that don't do enough of ieee to represent
:infinity ?)

The only thing that would worry me about this is possible breakage of
existing uses of inf or NaN as a bareword.

And of course people will then want to write C< for (1 .. inf) >. :)

Hugo
0
hv
7/17/2003 3:45:44 PM
Reply: