perldelta584
Nicholas Clark
I've bumped lots of version numbers and minor tidying stuff like that, but
ran out of time. (And I've still to check that everyone with Changes in
the Changelog is in AUTHORS - given that I'm aware of a couple already, I
want to make a systematic check. a.k.a. a perl script)
Anyway, I figured I needed to write a perldelta for 5.8.4 :-)
Before I began I thought "mmm, this will be a bit bare; not much has changed"
but then I started reading through the changelog and found that actually
rather a lot has been going on. And changes have come from from many
different people. So here's a big thank-you to everyone who has been
contributing to perl over the past 3 months. Rumours of Perl's demise are
greatly exaggerated.
(And just *how* many Perl conferences are there this year?)
Appended is a first draft for 5.8.4. In 5.8.3 we said
Detached threads aren't supported on Windows yet, as they may lead to
memory access violation problems.
Is this fixed now? If so, I'd like to note it. Also, I'm not sure where
in Perl's documentation to link the format improvements to.
Nicholas Clark
=head1 NAME
perldelta - what is new for perl v5.8.4
=head1 DESCRIPTION
This document describes differences between the 5.8.3 release and
the 5.8.4 release.
=head1 Incompatible Changes
Many minor bugs have been fixed. Scripts which happen to rely on previously
erroneous behaviour will consider these fixes as incompatible changes :-)
You are advised to perform sufficient acceptance testing on this release
to satisfy yourself that this does not affect you, before putting this
release into production.
The diagnostic output of Carp has been changed slightly, to add a space after
the comma between arguments. This makes it much easier for tools such as
web browsers to wrap it, but might confuse any automatic tools which perform
detailed parsing of Carp output.
The internal dump output has been improved, so that non-printable characters
such as newline and backspace are output in C<\x> notation, rather than
octal. This might just confuse non-robust tools which parse the output of
modules such as Devel::Peek.
=head1 Core Enhancements
=head2 Malloc wrapping
Perl can now be built to detect attempts at pathologically large assignments.
Previously such assignments would suffer from integer wrap-around during size
calculations causing a misallocation, which would crash perl, and could
theoretically be used for "stack smashing" attacks. The wrapping defaults to
enabled on platforms where we know it works (AIX, BSDi, Darwin, DEC OSF,
FreeBSD, HP/UX, GNU Linux, OpenBSD, Solaris, VMS and Win32) and defaults to
disabled on other platforms.
=head2 Unicode Character Database 4.0.1
The copy of the Unicode Character Database included in Perl 5.8 has
been updated to 4.0.1 from 4.0.0.
=head2 suidperl less insecure
Paul Szabo has analysed and patched C<suidperl> to remove existing known
insecurities. Currently there are no known holes in C<suidperl>, but
previous experience shows that we cannot be confident that these were the
last. For new projects the core perl team would strongly recommend that you
use dedicated, single purpose security tools such as C<sudo> in preference
to C<suidperl>.
=head2 format
In addition to bug fixes, C<format>'s features have been enhanced. See XXX
=head1 Modules and Pragmata
The (mis)use of C</tmp> in core modules and documentation has been tidied up.
Not all modules with dual lives on CPAN have had these changes applied yet.
=over 4
=item Attribute::Handlers
=item B
=item Benchmark
=item CGI
=item Carp
=item Cwd
=item Exporter
=item File::Find
=item IO
=item IPC::Open3
=item Local::Maketext
=item Math::BigFloat
=item Math::BigInt
=item Math::BigRat
=item MIME::Base64
=item ODBM_File
=item POSIX
=item Shell
=item Socket
There is experimental support for Linux abstract Unix domain sockets.
=item Storable
=item Switch
Synced with the CPAN 2.10 release
=item Sys::Syslog
C<syslog()> can now use numeric constants for facility names and priorities,
in addition to strings.
=item Term::ANSIColor
=item Term::Unicode
=item Time::HiRes
=item Unicode::UCD
=item Win32
Win32.pm/Win32.xs has moved from the libwin32 module to core Perl
=item base
=item open
=item threads
XXX Win32 detached threads?
=item utf8
=back
=head1 Performance Enhancements
=over 4
=item *
Accelerated Unicode case mappings (C</i>, C<lc>, C<uc>, etc).
=item *
In place sort optimised (eg C<@a = sort @a>)
=item *
Unnecessary assignment optimised away in
my $s = undef;
my @a = ();
my %h = ();
=item *
Optimised C<map> in scalar context
=back
=head1 Installation and Configuration Improvements
The build process on both VMS and Windows has had several minor improvements
made. Perl should now build on Windows 95. C<perl.exe> on Windows now has a
"Camel" logo icon. The use of a camel with Perl is a trademark of O'Reilly
and Associates, and is used in the Perl core distribution with their
permission. On Windows Borland's C compiler can now compile perl with PerlIO
and/or USE_LARGE_FILES enabled.
Perl should build cleanly on Stratus VOS once more.
=head1 Selected Bug Fixes
More utf8 bugs fixed, notably in how C<chomp>, C<chop>, C<send>, and
C<syswrite> and interact with utf8 data. Concatenation now works correctly
when C<use bytes;> is in scope.
The "const in void context" warning has been suppressed for a constant in an
optimised-away boolean expression such as C<5 || print;>
C<perl -i> could C<fchmod(stdin)> by mistake. This is serious if stdin is
attached to a terminal, and perl is running as root. Now fixed.
=head1 New or Changed Diagnostics
C<Carp> and the internal diagnostic routines used by C<Devel::Peek> have been
made clearer, as described in L</Incompatible Changes>
=head1 Changed Internals
Some bugs have been fixed in the hash internals. Restricted hashes and
their place holders are now allocated and deleted at slightly different times,
but this should not be visible to user code.
=head1 Future Directions
Code freeze for the next maintenance release (5.8.5) is will be on 30th
June 2004, with release by mid July.
=head1 Reporting Bugs
If you find what you think is a bug, you might check the articles
recently posted to the comp.lang.perl.misc newsgroup and the perl
bug database at http://bugs.perl.org. There may also be
information at http://www.perl.org, the Perl Home Page.
If you believe you have an unreported bug, please run the B<perlbug>
program included with your release. Be sure to trim your bug down
to a tiny but sufficient test case. Your bug report, along with the
output of C<perl -V>, will be sent off to per...@perl.org to be
analysed by the Perl porting team. You can browse and search
the Perl 5 bugs at http://bugs.perl.org/
=head1 SEE ALSO
The F<Changes> file for exhaustive details on what changed.
The F<INSTALL> file for how to build Perl.
The F<README> file for general stuff.
The F<Artistic> and F<Copying> files for copyright information.
=cut
Stas Bekman
> Anyway, I figured I needed to write a perldelta for 5.8.4 :-)
> =item Switch
>
> Synced with the CPAN 2.10 release
May be it's just me, but I read it as CPAN.pm 2.10 release. May be it's better
to rephrase it as:
Synced with its CPAN version 2.10
?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:st...@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Robert Spier
At least 13.
h...@crypt.org
:=head2 Malloc wrapping
:
:Perl can now be built to detect attempts at pathologically large assignments.
That sounds like assigning a bigint. I'd suggest:
Perl can now be built to detect attempts to assign pathologically large
chunks of memory.
:=head1 Modules and Pragmata
:
:The (mis)use of C</tmp> in core modules and documentation has been tidied up.
:Not all modules with dual lives on CPAN have had these changes applied yet.
I don't think "dual life" is a term widely recognised outside p5p.
I'd suggest something like:
Some modules available both within the perl core and independently from
CPAN ("dual-life modules") have not yet had these changes applied.
.. preferably also making clear whether the changes are unapplied only
in the CPAN avatar, or both on CPAN and in the core.
:=over 4
:
:=item Attribute::Handlers
Is this the list of dual-life modules not yet patched for /tmp abuse?
Or is these a missing heading 'updated modules'?
:=head1 Installation and Configuration Improvements
:
:The build process on both VMS and Windows has had several minor improvements
:made. Perl should now build on Windows 95. C<perl.exe> on Windows now has a
:"Camel" logo icon. The use of a camel with Perl is a trademark of O'Reilly
:and Associates, and is used in the Perl core distribution with their
:permission.
Does this need additional information about the extent of O'Reilly's
permission? That is to say, can Joe Bloggs download perl without
infringing on their ownership? Attach the icon to his perl installation?
Or to a perl program he has written? Or on his perl-powered website?
:Code freeze for the next maintenance release (5.8.5) is will be on 30th
:June 2004, with release by mid July.
I believe the accepted form for the time-traveller's 'future present'
tense is "wollen be".
Hugo
Nicholas Clark
> I'm getting a bunch of bugs at the moment to the effect that "<Random
> suid script> doesn't work!!!". You may wish to add a note here
> something like:
>
> You may no longer invoke suidperl directly, any script which uses
> #!/usr/bin/suidperl should be changed to use #!/usr/bin/perl.
Thanks. I actually put it in the "incompatible changes" section.
On Sun, Apr 04, 2004 at 06:38:36PM -0700, Stas Bekman wrote:
> Nicholas Clark wrote:
> >Anyway, I figured I needed to write a perldelta for 5.8.4 :-)
> [...]
> >=item Switch
> >
> >Synced with the CPAN 2.10 release
>
> May be it's just me, but I read it as CPAN.pm 2.10 release. May be it's
> better to rephrase it as:
>
> Synced with its CPAN version 2.10
Thanks. I used your wording.
Nicholas Clark
Nicholas Clark
> Nicholas Clark <ni...@ccl4.org> wrote:
> :The build process on both VMS and Windows has had several minor improvements
> :made. Perl should now build on Windows 95. C<perl.exe> on Windows now has a
> :"Camel" logo icon. The use of a camel with Perl is a trademark of O'Reilly
> :and Associates, and is used in the Perl core distribution with their
> :permission.
>
> Does this need additional information about the extent of O'Reilly's
> permission? That is to say, can Joe Bloggs download perl without
> infringing on their ownership? Attach the icon to his perl installation?
> Or to a perl program he has written? Or on his perl-powered website?
I don't know fully. I'm not a lawyer, and I don't want to be one.
The specific message is
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-01/msg00726.html
Based on that text, anyone can download the source no problem. They can build
it locally no problem. From it I'm not sure about non-profits distributing
Windows binaries built from our source. From it I get the impression that
for-profits distributing perl would need to contact O'Reilly. I intentionally
left my wording vague - if you think you need to check on doing something you
probably do.
Maybe a better wording would be
C<perl.exe> on Windows now has a "Camel" logo icon. The use of a camel with
the topic of Perl is a trademark of O'Reilly and Associates Inc., and is used
with their permission (ie distribution of the source, compiling a Windows
executable from it, and using that executable locally). Use of the supplied
camel for anything other than a perl executable's icon is specifically not
covered, and anyone wishing to redistribute perl binaries I<with> the icon
would be wise to check directly with O'Reilly beforehand.
(I'm confident that this won't impinge on distributions such as Debian which
are very careful about their legal requirements, as there isn't Debian/Win32
yet. None of the binaries they compile would ship with the icon in them, and
the source they distribute is either a vanilla mirroring of ours (so has
permission) or they could patch to delete the "offending" files with no loss
of functionality. It won't affect ActiveState, as they use a different icon.)
[Other stuff applied]
Nicholas Clark
Steve Hay
>On Mon, Apr 05, 2004 at 03:37:40AM +0100, h...@crypt.org wrote:
>
>
>>Nicholas Clark <ni...@ccl4.org> wrote:
>>
>>
>
>
>
>>:The build process on both VMS and Windows has had several minor improvements
>>:made. Perl should now build on Windows 95. C<perl.exe> on Windows now has a
>>:"Camel" logo icon. The use of a camel with Perl is a trademark of O'Reilly
>>:and Associates, and is used in the Perl core distribution with their
>>:permission.
>>
>>Does this need additional information about the extent of O'Reilly's
>>permission? That is to say, can Joe Bloggs download perl without
>>infringing on their ownership? Attach the icon to his perl installation?
>>Or to a perl program he has written? Or on his perl-powered website?
>>
>>
>
>I don't know fully. I'm not a lawyer, and I don't want to be one.
>The specific message is
>http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-01/msg00726.html
>
>Based on that text, anyone can download the source no problem. They can build
>it locally no problem. From it I'm not sure about non-profits distributing
>Windows binaries built from our source. From it I get the impression that
>for-profits distributing perl would need to contact O'Reilly. I intentionally
>left my wording vague - if you think you need to check on doing something you
>probably do.
>
I would agree with all of that (though, of course, IANAL either).
>
>Maybe a better wording would be
>
>C<perl.exe> on Windows now has a "Camel" logo icon. The use of a camel with
>the topic of Perl is a trademark of O'Reilly and Associates Inc., and is used
>with their permission (ie distribution of the source, compiling a Windows
>executable from it, and using that executable locally). Use of the supplied
>camel for anything other than a perl executable's icon is specifically not
>covered, and anyone wishing to redistribute perl binaries I<with> the icon
>would be wise to check directly with O'Reilly beforehand.
>
Yes, I think the extra detail there is well worth it. The
acknowledgement in README.win32 should probably be expanded in the same
way too -- people are more likely to look at that than the perl583delta
in later (post-5.8.3) versions of Perl.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Steve Hay
>In 5.8.3 we said
>
> Detached threads aren't supported on Windows yet, as they may lead to
> memory access violation problems.
>
>Is this fixed now? If so, I'd like to note it.
>
Yes, it's fixed. The threads (excuse the pun) discussing it are here:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-12/msg01029.html
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-01/msg00008.html
culminating in change 22201 which has been applied to maint-5.8.
I also tried out the test program in the first of those threads (albeit
using Thread::Queue instead of threads::shared::queue, which doesn't
seem to exist?) and it does indeed crash under perl-5.8.2 [sic] and run
OK with the current maint-5.8. Bizarrely, it seems to run OK under
perl-5.8.3 too. I don't understand why, but at least it works now ;)
Jan Dubois
wrote:
>> Detached threads aren't supported on Windows yet, as they may lead to
>> memory access violation problems.
>>
>I also tried out the test program in the first of those threads (albeit
>using Thread::Queue instead of threads::shared::queue, which doesn't
>seem to exist?) and it does indeed crash under perl-5.8.2 [sic] and run
>OK with the current maint-5.8. Bizarrely, it seems to run OK under
>perl-5.8.3 too. I don't understand why, but at least it works now ;)
Did you test it with your own perl-5.8.3 or with ActivePerl 5.8.3 build
809. I did put the 22201 patch into build 809 to give it some bigger
exposure, so you wouldn't see the test failure there. If you were
testing against core 5.8.3, then I don't know why it passed either.
Cheers,
-Jan
Elizabeth Mattijsen
>...(albeit
>using Thread::Queue instead of threads::shared::queue, which doesn't
>seem to exist?)
threads::shared::queue was the name of the module for shared queues
before 5.8.0 came out. To create a consistent namespace for thread
related modules, it was (rather late) decided that the Thread::
namespace should be used for thread related modules. And this would
apply to thread related modules in core as well. So
threads::shared::queue was renamed Thread::Queue. (that is, if my
memory serves me well).
Liz
Steve Hay
>On Mon, 05 Apr 2004 12:03:45 +0100, Steve Hay <stev...@uk.radan.com>
>wrote:
>
>
>
>>> Detached threads aren't supported on Windows yet, as they may lead to
>>> memory access violation problems.
>>>
>>>
>>>
>>I also tried out the test program in the first of those threads (albeit
>>using Thread::Queue instead of threads::shared::queue, which doesn't
>>seem to exist?) and it does indeed crash under perl-5.8.2 [sic] and run
>>OK with the current maint-5.8. Bizarrely, it seems to run OK under
>>perl-5.8.3 too. I don't understand why, but at least it works now ;)
>>
>>
>
>Did you test it with your own perl-5.8.3 or with ActivePerl 5.8.3 build
>809. I did put the 22201 patch into build 809 to give it some bigger
>exposure, so you wouldn't see the test failure there.
>
I used 809 because I didn't have any other threaded 5.8.3 to hand. So
that explains it.
Thanks,
h...@crypt.org
:Maybe a better wording would be
:
:C<perl.exe> on Windows now has a "Camel" logo icon. The use of a camel with
:the topic of Perl is a trademark of O'Reilly and Associates Inc., and is used
:with their permission (ie distribution of the source, compiling a Windows
:executable from it, and using that executable locally). Use of the supplied
:camel for anything other than a perl executable's icon is specifically not
:covered, and anyone wishing to redistribute perl binaries I<with> the icon
:would be wise to check directly with O'Reilly beforehand.
That seems much clearer. I'd s/would be wise to/should/, but otherwise it
seems fine.
Hugo
Craig A. Berry
ni...@ccl4.org (Nicholas Clark) wrote:
> =head2 Malloc wrapping
> The wrapping defaults to
> enabled on platforms where we know it works (AIX, BSDi, Darwin, DEC OSF,
> FreeBSD, HP/UX, GNU Linux, OpenBSD, Solaris, VMS and Win32) and defaults to
> disabled on other platforms.
It looks to me like it never defaults to enabled but instead requires
either -Dusedevel or -Dusemallocwrap. It seems we should change either
the doc or Configure (and configure.com) -- I don't know which.
Nicholas Clark
> It looks to me like it never defaults to enabled but instead requires
> either -Dusedevel or -Dusemallocwrap. It seems we should change either
> the doc or Configure (and configure.com) -- I don't know which.
Aha. So I misunderstood.
No, I don't know either. How easy (and quick) is it to change configure.com?
I like having the wrapping as default (generally) but I don't want to break
things at this late stage.
Nicholas Clark
Nicholas Clark
> That seems much clearer. I'd s/would be wise to/should/, but otherwise it
> seems fine.
Yes. Less words and more defensive. Thanks
Nicholas Clark
Nicholas Clark
>
> On Monday, April 05, 2004, at 09:06AM, Nicholas Clark <ni...@ccl4.org> wrote:
>
> >On Mon, Apr 05, 2004 at 07:38:11AM -0500, Craig A. Berry wrote:
> >
> >> It looks to me like it never defaults to enabled but instead requires
> >> either -Dusedevel or -Dusemallocwrap. It seems we should change either
> >> the doc or Configure (and configure.com) -- I don't know which.
> >
> >Aha. So I misunderstood.
> >
> >No, I don't know either. How easy (and quick) is it to change configure.com?
>
> The patch makes usemallocwrap the default unless explicitly disabled
> with -Uusemallocwrap.
Thanks applied (22656)
> Configure and any other platform-specific configuration scripts would need
> a corresponding change.
Aha. I already made OS specific hints files for all the Unixes that we smoke,
as they are all working, and Steve Hay tested and supplied a patch (22579)
that makes it the default on Windows.
Nicholas Clark
Craig Berry
On Monday, April 05, 2004, at 09:06AM, Nicholas Clark <ni...@ccl4.org> wrote:
>On Mon, Apr 05, 2004 at 07:38:11AM -0500, Craig A. Berry wrote:
>
>> It looks to me like it never defaults to enabled but instead requires
>> either -Dusedevel or -Dusemallocwrap. It seems we should change either
>> the doc or Configure (and configure.com) -- I don't know which.
>
>Aha. So I misunderstood.
>
>No, I don't know either. How easy (and quick) is it to change configure.com?
Very. Patch attached (hopefully not mangled by this webmail client).
The patch makes usemallocwrap the default unless explicitly disabled
with -Uusemallocwrap.
Configure and any other platform-specific configuration scripts would need
a corresponding change.
H.Merijn Brand
> =head2 Malloc wrapping
>
> Perl can now be built to detect attempts at pathologically large assignments.
> Previously such assignments would suffer from integer wrap-around during size
> calculations causing a misallocation, which would crash perl, and could
> theoretically be used for "stack smashing" attacks. The wrapping defaults to
> enabled on platforms where we know it works (AIX, BSDi, Darwin, DEC OSF,
It is disabled on AIX 4.3 for native C compiler
> FreeBSD, HP/UX, GNU Linux, OpenBSD, Solaris, VMS and Win32) and defaults to
> disabled on other platforms.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.3, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 9.0, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
H.Merijn Brand
>
> In addition to bug fixes, C<format>'s features have been enhanced. See XXX
XXX being to be replaced with what?
Steve Hay
>On Mon 05 Apr 2004 00:41, Nicholas Clark <ni...@ccl4.org> wrote:
>
>
>>=head2 Malloc wrapping
>>
>>Perl can now be built to detect attempts at pathologically large assignments.
>>Previously such assignments would suffer from integer wrap-around during size
>>calculations causing a misallocation, which would crash perl, and could
>>theoretically be used for "stack smashing" attacks. The wrapping defaults to
>>enabled on platforms where we know it works (AIX, BSDi, Darwin, DEC OSF,
>>
>>
>
>It is disabled on AIX 4.3 for native C compiler
>
>
>
>>FreeBSD, HP/UX, GNU Linux, OpenBSD, Solaris, VMS and Win32)
>>
and disabled on Win32 for Borland compiler?
>>and defaults to
>>disabled on other platforms.
>>
>>
>
>
>
Abe Timmerman
Brand:
> On Mon 05 Apr 2004 00:41, Nicholas Clark <ni...@ccl4.org> wrote:
> > =head2 Malloc wrapping
> >
> > Perl can now be built to detect attempts at pathologically large
> > assignments. Previously such assignments would suffer from integer
> > wrap-around during size calculations causing a misallocation, which would
> > crash perl, and could theoretically be used for "stack smashing" attacks.
> > The wrapping defaults to enabled on platforms where we know it works
> > (AIX, BSDi, Darwin, DEC OSF,
>
> It is disabled on AIX 4.3 for native C compiler
>
> > FreeBSD, HP/UX, GNU Linux, OpenBSD, Solaris, VMS and Win32) and defaults
> > to disabled on other platforms.
It appears to be enabled on NetBSD (i386) as well.
Good luck,
Abe
--
Schwern> Anything else you'd like? Side order of fries? Clean your stables?
Schwern> Get you an apple? Part the Red Sea?
I guess I otherwise would sense some sarcasm in your voice but
unfortunately my sarcasm-o-meter burned out years ago from prolonged
exposure to myself.
-- Jarkko Hietaniemi on p5p @ 2002-02-03
Nicholas Clark
> > theoretically be used for "stack smashing" attacks. The wrapping defaults to
> > enabled on platforms where we know it works (AIX, BSDi, Darwin, DEC OSF,
>
> It is disabled on AIX 4.3 for native C compiler
On Thu, Apr 15, 2004 at 10:29:47AM +0100, Steve Hay wrote:
> and disabled on Win32 for Borland compiler?
I added "most" to these two.
On Thu, Apr 15, 2004 at 11:45:05AM +0200, Abe Timmerman wrote:
> It appears to be enabled on NetBSD (i386) as well.
It's defaulting to enabled with -Dusedevel, so all the 5.9.2 smokes will be
using it, as well as any 5.8.x configured with -Dusedevel.
Otherwise it defaults to disabled, but a lot of platform hints files are
turning it on. NetBSD's hints file isn't, because there didn't seem to be
clean pass smoke results when I checked everywhere.
Nicholas Clark
H.Merijn Brand
That's why I responded. AIX-4.3 hints explicitely turns
it OFF for native C compiler. Whatever -Dusedevel is
> Nicholas Clark
Abe Timmerman
Clark:
> On Thu, Apr 15, 2004 at 11:45:05AM +0200, Abe Timmerman wrote:
> > It appears to be enabled on NetBSD (i386) as well.
>
> It's defaulting to enabled with -Dusedevel, so all the 5.9.2 smokes will be
> using it, as well as any 5.8.x configured with -Dusedevel.
That explains it then. It also means *all* smokes as Test::Smoke blindly calls
Configure with "-des -Dusedevel" for all versions of perl.
> Otherwise it defaults to disabled, but a lot of platform hints files are
> turning it on. NetBSD's hints file isn't, because there didn't seem to be
> clean pass smoke results when I checked everywhere.
My "wodan" (NetBSD 1.5 i386) has been emitting white-smoke for quite some time
now.
It looks like alian's spac-box has some Failures but are they related?
(The Test-Smoke database is also on: http://db.Test-Smoke.org/)
Anyway, I only wanted to report what I saw in config.sh; you're the gov ;)
Good luck,
Abe
--
NickC> After I've eaten I'll have proper look at the modperl source.
Grumble, grumble. What's with all this sleep and eat stuff? I never
remember Jarkko having to sleep or eat.
-- Yitzchak Scott-Thoennes on p5p @ 2003-10-31