data written on ebcdic
I run the following on an ebcdic platform (perl-5.8.6), $BOM = chr(0xFEFF); open(UTF_PL, :raw:encoding(utf16le), utf.pl) or die utf.pl($enc,$tag): $!; print UTF_PL $BOM; print UTF_PL 1; should the data that is written using PerlLIO_write, be \xFF \xFE \xF1 or should it be \xFF \xFE \x31 ? Thanks in advance, Rajarshi. __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 11:12:34PM -0700, Glenn Linderman wrote: Yep, there is more to a file system than case sensitivity. But I'm hoping that you probe as needed, and cache results for future requests, rather than probing for all this info including if it is never used... and walk softly, perturbing as little as possible to obtain the information desired. The plan goes something like this: * Offer to do a full probe at installation time (when we will likely be root). Query the user about things like mount points. Cache the results. * When cached results aren't available (or have been flushed) each accessor will do its probe on demand. An optimization might be to combine multiple similar probes together as one. * If the user wants, they can just say a given mount point is of a given known file system type thus avoiding all probing. * The administrator can at any time ask for a reprobe like the one done at installation time should the mount points change. You're right, though. If I can make the probe read-only so much the better. Case-sensitivity is really the only one I can think of how to do read-only. Fortunately, its also by far the most common concern. # Is this determined by the OS or the file system? File system. Win32 supports FAT and NTFS, only the latter supports junction points and reparse points. $fs-can_symlink_files; $fs-can_hardlink_files; $fs-can_symlink_dirs; $fs-can_hardlink_dirs; But does Perl translate them into symlinks and hard links? If it doesn't then we'll never see it. Which is, in the end, all we care about. Quite an ambitious list. I can't imagine that you can probe all of that stuff in an OS independent manner. But I'm willing to watch, and be impressed. I've done most of it already here and there. The real hold up is structuring the probing system so its extensable and doesn't wind up looking like Configure. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: [perl #34180] segfault in perl_clone under ithreads and custom PerlIO layer
Dave Mitchell wrote:
On Sat, Feb 19, 2005 at 02:20:28AM -, Stas Bekman wrote:
We have yet another chicken-n-egg problem with perl_clone. If you do a
simple:
use threads;
my $thread = threads-create(sub {}, undef)
and STDOUT is opened to some PerlIO layer, an attempt to clone it will be
performed. The problem is that this cloning happens too early:
do you have a complete script that reproduces this?
something simple like
binmode STDOUT, ':utf8';
didn't segfault
Under mod_perl2
package My::Bug;
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::Const -compile = qw(OK);
use threads;
sub handler {
my $r = shift;
my $thread = threads-create(sub {}, undef);
$thread-join;
$r-content_type('text/plain');
print 'found a bug';
return Apache2::Const::OK;
}
1;
and config:
Location /bug
SetHandler perl-script
PerlResponseHandler My::Bug
/Location
I've attached a tarball that reproduces the problem. Assuming that you've
mod_perl2 installed, unpack it and run:
perl Makefile.PL -httpd /home/stas/httpd/prefork/bin/httpd
make
make test
(you should get a segfault)
(adjust the path to the location of your httpd)
Thanks Dave.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
bug-reporting-skeleton-mp2.tar.gz
Description: GNU Zip compressed data
Re: [perl #34180] segfault in perl_clone under ithreads and custom PerlIO layer
A few other related things using APR::PerlIO which can be used outside
mod_perl:
#foo
use APR::Pool;
use APR::PerlIO;
my $pool = APR::Pool-new;
my $filename = /tmp/file;
open my $fh, :APR, $filename, $pool or die $!;
use threads;
my $thread = threads-create(sub {}, undef);
$thread-join;
% perl-5.8.6-ithread /tmp/foo
*** glibc detected *** double free or corruption (!prev): 0x080f6518 ***
Abort
% perl-5.8.7-ithread /tmp/foo
so it looks like it was fixed in 5.8.7.
The following was also segfaulting with 5.8.6, but not with 5.8.7:
--
use APR::Pool;
use APR::PerlIO;
my $pool = APR::Pool-new;
my $filename = /tmp/file;
close STDOUT;
open STDOUT, :APR, $filename, $pool or die $!;
use threads;
my $thread = threads-create(sub {}, undef);
$thread-join;
--
Adding dup is still not good with 5.8.7:
--
use APR::Pool;
use APR::PerlIO;
my $pool = APR::Pool-new;
my $filename = /tmp/file;
close STDOUT;
open STDOUT, :APR, $filename, $pool or die $!;
open OLDOUT, STDOUT or die $!;
use threads;
my $thread = threads-create(sub {}, undef);
$thread-join;
--
% perl-5.8.7-ithread /tmp/foo2
leaked PerlIOAPR handle 0x812d0e8 during global destruction.
leaked PerlIOAPR handle 0x8065208 during global destruction.
So this is stilll an issue. Do you think it's a bug in perl?
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Documenation hint: Name your arguments
Michael G Schwern wrote: On Wed, Jul 06, 2005 at 06:30:10PM +0200, Rafael Garcia-Suarez wrote: On 7/6/05, Michael G Schwern [EMAIL PROTECTED] wrote: I prefer no formatting because $foo is already visually distinctive enough. We're used to seeing $foo from reading code. Moreover pod2text adds quotes around code inside C, so $foo sometimes breaks the clarity of the text. I'm also not a fan of C for simple expressions like function() for similar reasons. Its already visually distinctive and the quotes don't really help things. And I'm lazy. True, but Cfunction() is turned into a link to =item function by pod2html, which is often useful. And I'm not lazy. (Well, not *that* lazy, anyway.) 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.
Re: [PATCH] Further lies in the File::Basename docs
On 7/7/05, Michael G Schwern [EMAIL PROTECTED] wrote: Its the most accurate with the least proliferation of platform-specific hacks. Is the core really the place for probing ? I don't expect fs probing code to be sufficiently stable in the near future to go in the core. Portability is always harder than you think.
Re: [PATCH] Further lies in the File::Basename docs
On 7/7/05, Michael G Schwern [EMAIL PROTECTED] wrote: The plan goes something like this: * Offer to do a full probe at installation time (when we will likely be root). Query the user about things like mount points. Cache the results. In those days of package management software, most perls and perl modules aren't configured / compiled on the same system they'll be installed on.
Re: [PATCH] Further lies in the File::Basename docs
On Thu, Jul 07, 2005 at 10:13:01AM +0200, Rafael Garcia-Suarez wrote: On 7/7/05, Michael G Schwern [EMAIL PROTECTED] wrote: Its the most accurate with the least proliferation of platform-specific hacks. Is the core really the place for probing ? As always it goes on CPAN first. Worry about core issues later. I don't expect fs probing code to be sufficiently stable in the near future to go in the core. Portability is always harder than you think. You're telling me?! *looks at MakeMaker* -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: [PATCH] Further lies in the File::Basename docs
On Thu, Jul 07, 2005 at 10:18:13AM +0200, Rafael Garcia-Suarez wrote: On 7/7/05, Michael G Schwern [EMAIL PROTECTED] wrote: The plan goes something like this: * Offer to do a full probe at installation time (when we will likely be root). Query the user about things like mount points. Cache the results. In those days of package management software, most perls and perl modules aren't configured / compiled on the same system they'll be installed on. This is up to the package manager to deal with. A simple solution is to have a post-install script which runs the initial probe. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: Documenation hint: Name your arguments
On Thu, Jul 07, 2005 at 09:03:54AM +0100, Steve Hay wrote: True, but Cfunction() is turned into a link to =item function by pod2html, which is often useful. If pod2man already assumes foo() is a function why not pod2html? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: [PATCH] Pod::Html - correctly link to =item's on the same page
On Tue, Jul 05, 2005 at 06:22:02PM +0100, Steve Hay wrote: So I've applied your patch, together with my test (marked as TODO since it currently fails) as change 25083. Note that it is all one test, though, so the newly fixed bit isn't actually being tested until the TODO gets resolved :-( Thanks! Here's a patch to switch the links in perlglossary back to L instead of C, plus some other minor corrections, and restoring some of Larry's original prose where I'd fiddled with it to make the C links work. glosupd.patch.gz Description: application/gunzip
Re: [PATCH] Further lies in the File::Basename docs
Michael G Schwern wrote:
Sometimes you want to write a patch just for the subject line. :)
Thanks - applied as change 25089.
A couple of minor POD changes again (another podchecker nit, and C
around function names, for now at least) plus a fix for a serious bug
which completely screwed *everything* in Win32-land: the assignment to
@Ignore_Case and @Types was carried out too late - long after the
initial call to fileparse_set_fstype()! I've put the assignment in a
BEGIN { } block to fix it, and threw the fileparse_set_fstype() function
itself into the same scope since it is the only thing requiring access
to those lexicals.
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.
Re: Build of mod_perl 2.0.0 fails on bleadperl - no more HvPMROOT()
Apologies for not replying earlier. I'm now back to work on this issue.
Nicholas Clark wrote:
On Sun, Jun 12, 2005 at 07:29:02PM +1000, Stas Bekman wrote:
Thanks Steve for the suggestion, but this is not good since it requires
aTHX + PERL_SET_CONTEXT which creates a chicken and an egg problem. Any
other more suitable candidates to use instead of:
HvPMROOT(*Perl_Imodglobal_ptr(thx)) = (PMOP*)interp
?
It needs to be really quick, as we already have a way too many context
switch overheads in the perl-core.
Is all this messing around with hiding things in HvPMROOT because really
mod_perl 2 would like a private pointer of its own in the perl interpreter
structure?
No, it wants to have a reference from the current perl interpreter to
modperl_interp_t which is needed to be able to put the perl interpreter
back to the pool of interpreters and such.
struct modperl_interp_t {
modperl_interp_pool_t *mip;
PerlInterpreter *perl;
int num_requests;
U8 flags;
request_rec *request;
int refcnt;
#ifdef MP_TRACE
unsigned long tid;
#endif
};
Of course we could have created a special entry in modglobal and store it
there, but since the operation of reading and setting of modperl_interp_t
is very frequent, it must be very fast. I suppose Doug has chosen
HvPMROOT(*Perl_Imodglobal_ptr(thx)) as the quickest possible way to
accomplish that.
If you really really feel the need to cheat then you have the choice of these:
#define xhv_keys xiv_u.xivu_iv
typedef struct {
STRLEN xhv_fill; /* how full xhv_array currently is */
STRLEN xhv_max;/* subscript of last element of xhv_array */
union {
IV xivu_iv;/* integer value or pv offset */
UV xivu_uv;
void * xivu_p1;
} xiv_u;
MAGIC* xmg_magic; /* magic for scalar array */
HV* xmg_stash; /* class package */
} xpvhv_allocated;
Only xmg_magic and xmg_stash aren't needed for the operation of a regular hash.
I've no idea what modglobal_ptr gets used for throughout the perl codebase,
but hanging something that isn't MAGIC* from xmg_magic feels like a bad plan.
You mean because it might be used later on for some purpose? If so any
other ideas for a quick stash inside the interpreter that is not used by
perl itself? May be something else besides modglobal?
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
[perl #36477] File::Basename basename() bug
# New Ticket Created by Jens Luedicke # Please include the string: [perl #36477] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36477 There is a bug in basename() (Module File::Basename): According to the manpage: basename The basename() routine returns the first element of the list produced by calling fileparse() with the same arguments, except that it always quotes metacharacters in the given suffixes. It is provided for programmer compatibility with the Unix shell command basename(1). The bug: basename() doesn't return '/' for parameter '/' -- Jens Luedicke web: http://perldude.de/
Re: [perl #22236] File::Basename behavior is misleading
Michael G Schwern via RT wrote: Attached is a patch to make basename() strip trailing path seperators before processing as well as docs to that effect and more tests. I've also documented the dirname($path) . '/' . basename($path) assertation. It also consolidates all the trailing path seperator stripping into one function so we don't have repeat the code in dirname() and basename(). Thanks - applied as change 25090 (with one or two C's again). 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.
Smoke [5.9.3] 25088 FAIL(F) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25088 fixit.xs4all.nl: Pentium II (i386/1 cpu) onbsd/os - 4.1 using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release) smoketime 3 hours 56 minutes (average 1 hour 58 minutes) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25088 Configuration (common) none --- - F F - - -Duse64bitint O O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] -Duse64bitint ../t/op/int.t...FAILED 11 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
Re: [PATCH] Mention File::Spec in File::Basename
Michael G Schwern wrote: My last patch to File::Basename, I swear. This one mentions File::Spec as an alternative as well as adding a SEE ALSO section. Thanks - applied as change 25091. I also remembered to bump $VERSION up this time :-) podchecker complained about the Ldirname(1) and Lbasename(1) on line 375: *** WARNING: (section) in 'dirname(1)' deprecated at line 375 *** WARNING: (section) in 'basename(1)' deprecated at line 375 but other man pages also use that style, and I'm not sure what one is supposed to do instead, so I left it. 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.
Re: [PATCH] Pod::Html - correctly link to =item's on the same page
Yitzchak Scott-Thoennes wrote: On Tue, Jul 05, 2005 at 06:22:02PM +0100, Steve Hay wrote: So I've applied your patch, together with my test (marked as TODO since it currently fails) as change 25083. Note that it is all one test, though, so the newly fixed bit isn't actually being tested until the TODO gets resolved :-( Thanks! Here's a patch to switch the links in perlglossary back to L instead of C, plus some other minor corrections, and restoring some of Larry's original prose where I'd fiddled with it to make the C links work. podchecker emits tons of warnings and errors after applying the patch. There were no warnings or errors before :-( Any chance you could fix it up and resend? 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.
recent blead changes have introduced tainting problems
i'm trying to get mod_perl2 working with blead, something has changed with the tainting, I now get: eval_sv(123;, G_SCALAR|G_KEEPERR); die with: Insecure dependency in eval_sv() while running with -T Further checking shows that the TAINT flag gets raised after this code (preceding the eval_sv line above): GV *gv = gv_fetchpv(0, TRUE, SVt_PV); save_scalar(gv); /* local $0 */ running TAINT_NOT after it fixes the problem Dave? Can you reproduce this problem? Things work fine with 5.8.x -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [perl #24170] ReadParse in the CGI docs
Michael G Schwern via RT wrote:
[EMAIL PROTECTED] - Thu Oct 09 08:06:20 2003]:
use CGI;
CGI::ReadParse
print The value of the antique is $in{antique}.\n;
Adding the missing ;, it will still not work since it's parsed as the
literal string CGI::ReadParse. The right way is of course:
use CGI;
CGI::ReadParse();
print The value of the antique is $in{antique}.\n;
He's right. This fix should be applied.
Indeed he is right. Fix now applied as change 25092.
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.
Re: Scalar leaked in 'local $0' under ithreads + taint mode
Dave Mitchell wrote:
On Thu, Feb 24, 2005 at 01:32:25PM +, Steve Hay wrote:
Stas Bekman wrote:
The following scalar leak is reproduced under any perl 5.8+ w/ithreads:
#!/usr/bin/perl -T
use Devel::Peek;
use threads;
local $0 = test; # == XXX: leaks scalar
my $thr = threads-new(sub { Dump $0 });
$thr-join;# == XXX: triggers the leak
[...]
Scalars leaked: 1
leaked: sv=0x816dc1c flags=0x084046007 refcnt=0, Perl interpreter: 0x8102770
As the dump shows that leaked scalar is MG_OBJ = 0x816dc1c. This magic
object is a taint magic (and it happens under -T).
Is this anything to do with the following comment found in
scope.c::S_save_scalar_at()
/* XXX SvMAGIC() is *shared* between osv and sv. This can
* lead to coredumps when both SVs are destroyed without one
* of their SvMAGIC() slots being NULLed. */
Looks like the leak has been fixed by my change #24942, which fixed
local() and magic (and specifically removed the code related to that XXX
comment above)
Hmm. I just retried this with current blead and I find that it
(apparently) works OK with a debug build, but crashes with a release build.
Fortunately, release builds on Win32 have debugging symbols anyway
(since they are stored in separate files), so I am able to get a stack
trace:
win32_checkTLS(interpreter * 0x73204441) line 57
PerlEnvGetenv(IPerlEnv * 0x01857670, const char * 0x280b79b8 `string')
line 454 + 19 bytes
PerlIO_debug(const char * 0x280b79e0 `string') line 461 + 14 bytes
PerlIO_clone(interpreter * 0x018b2ad4, interpreter * 0x00234494,
clone_params * 0x0140fc80) line 643
perl_clone_using(interpreter * 0x00234494, unsigned long 6, IPerlMem *
0x0185761c, IPerlMem * 0x01857638, IPerlMem * 0x01857654, IPerlEnv *
0x01857670, IPerlStdIO * 0x018576a8, IPerlLIO * 0x01857744, IPerlDir *
0x018577ac, IPerlSock * 0x018577d8, IPerlProc * 0x01857888) line 11383
perl_clone_host(interpreter * 0x00234494, unsigned long 6) line 315 + 67
bytes
perl_clone(interpreter * 0x00234494, unsigned long 6) line 11183 + 11 bytes
Perl_ithread_create(interpreter * 0x, sv * 0x, char *
0x018325e4, sv * 0x002354cc, sv * 0x01828c64) line 424 + 8 bytes
XS_threads_new(interpreter * 0x0002, cv * 0x018a83f4) line 687 + 32
bytes
Perl_pp_entersub(interpreter * 0x01234494) line 2789
Perl_runops_standard(interpreter * 0x00234494) line 38 + 45 bytes
S_run_body(interpreter * 0x00234494, long 1) line 2231 + 10 bytes
perl_run(interpreter * 0x00234494) line 2160 + 10 bytes
RunPerl(int 3, char * * 0x00232440, char * * 0x00232d08) line 217 + 6 bytes
PERL! mainCRTStartup + 227 bytes
KERNEL32! 77e8141a()
Do you guys get a similar effect with release vs debug builds?
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.
Re: recent blead changes have introduced tainting problems
On Thu, Jul 07, 2005 at 03:14:47PM +0300, Stas Bekman wrote: i'm trying to get mod_perl2 working with blead, something has changed with the tainting, I now get: eval_sv(123;, G_SCALAR|G_KEEPERR); die with: Insecure dependency in eval_sv() while running with -T does it still fail post change 25081 ? -- O Unicef Clearasil! Gibberish and Drivel! - Bored of the Rings
Re: recent blead changes have introduced tainting problems
On Thu, Jul 07, 2005 at 02:24:08PM +0100, Dave Mitchell wrote: On Thu, Jul 07, 2005 at 03:14:47PM +0300, Stas Bekman wrote: i'm trying to get mod_perl2 working with blead, something has changed with the tainting, I now get: eval_sv(123;, G_SCALAR|G_KEEPERR); die with: Insecure dependency in eval_sv() while running with -T does it still fail post change 25081 ? Ignore that, I can reproduce it now -- The Enterprise successfully ferries an alien VIP from one place to another without serious incident. -- Things That Never Happen in Star Trek #7
Re: [PATCH] bug with charnames::viacode(0x1234) and optimize it
On Wed, 6 Jul 2005 21:11:59 +0200, Tels [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Moin,
currently, charnames::viacode() does only take integers and strings, but
stumbles over hex strings, even though the code tries to handle them (but
fails due to a thinko):
Thanks, I applied it as change #25093
but I tried to maintain the meaning of the original comment with _getcode:
--8---
sub viacode
{
if (@_ != 1) {
carp charnames::viacode() expects one argument;
-return ()
+return;
}
my $arg = shift;
- my $code = _getcode($arg);
+ # this comes actually from Unicode::UCD, where it is the named
+ # function _getcode (), but it avoids the overhead of loading it
my $hex;
-
- if (defined $code) {
+ if ($arg =~ /^[1-9]\d*$/) {
$hex = sprintf %04X, $arg;
+ } elsif ($arg =~ /^(?:[Uu]\+|0[xX])?([[:xdigit:]]+)$/) {
+$hex = $1;
} else {
carp(unexpected arg \$arg\ to charnames::viacode());
return;
}
--8---
# perl -Mcharnames=:full -le 'print charnames::viacode(0x1234)'
ETHIOPIC SYLLABLE SEE
# perl -Mcharnames=:full -le 'print charnames::viacode(4660)'
ETHIOPIC SYLLABLE SEE
# perl -Mcharnames=:full -le 'print charnames::viacode(4660)'
ETHIOPIC SYLLABLE SEE
# perl -Mcharnames=:full -le 'print charnames::viacode(0x1234)'
Argument 0x1234 isn't numeric in sprintf
at /usr/local/lib/perl5/5.8.6/charnames.pm line 270.
NULL
The attached patch corrects that mistake, and also optimizes the function.
It inlines the subroutine _getcode(), which was used only once, and
streamlines the operations a bit.
A benchmark with both versions was also done. The new one was named
viacode2, and in the original one I replaced sprintf %04X, $arg with
sprintf %04X, $code to fix the hexstring bug to compare the
optimizations vs. straight bugfix:
Benchmark: running v(0x1234), v(0x1234), v2(0x1234), v2(0x1234) for at
least 5 CPU seconds...
v(0x1234): 4 (5.07 usr + 0.05 sys = 5.12 CPU) @ 113076/s (n=578953)
v(0x1234):6 (5.05 usr + 0.05 sys = 5.10 CPU) @ 173617/s (n=885448)
v2(0x1234): 5 (5.16 usr + 0.03 sys = 5.19 CPU) @ 158199/s (n=821057)
v2(0x1234): 5 (5.12 usr + 0.02 sys = 5.14 CPU) @ 221021/s (n=1136050)
The benchmark benched the cached version (once you looked up
viacode(1234), charnames will remember the result internally). Uncached
lookups are *much* slower, my system makes about 400 calls/s. The very
first calls is again _much_ slower, because charnames includes a 500K
file via do . Both uncached and very-first-call szenarios are unlikely
speed up, but not hurt, either.
Although all tests pass, the patch does not contain new tests for the now
working calling-types. These will come when I rewrote charnames.t to use
is() instead of printing ok or not ok (because it is quite hard to insert
a test in the middle, where it belongs).
Btw, can Carp::croak() ever return? I think the return statements after
carp() are superflouse and can be removed.
Best wishes,
Tels
- --
Signed on Wed Jul 6 20:59:00 2005 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
The campaign should combat the messages of pornography by putting signs
on buses saying sex with children is not OK. -- Mary Anne Layden in
ttp://tinyurl.com/6a9cy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iQEVAwUBQswtCHcLPEOTuEwVAQGNRgf+M83ORhpuUbgzA+XWcHlZVWqZNvD2L91c
Vh0dFmphRvZuOczEnr3BiOSr3nqNiT7JBGdqx1JZZ1MURju90spkNBPBtGvdwC+7
x08+iCkaPpGY5XtFK/l+IBCIFTVupRsmRnRwwLcT/dGYnTasrLO9qE/VW+rh1lH2
smRVVZAUgqJw0222fMJ/3icWIlo+2zpMevwoM7Lzefn/D/erW+eLqi6tJZIjpa9O
lBf436MG7TsCHML2Wqkvzwyi2dnTVsjxIOku1ymjW7aN0/e/gLSnRMbr47Fs0Eg7
U5J13bJ+sxw9qfdxSZqPbcKFEzQ8UxnnhSj4jrkdz7BvRZ8GypJDpw==
=96E8
-END PGP SIGNATURE-
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11,
AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 03:46:02PM -1000, Joshua Hoblitt wrote: On Wed, Jul 06, 2005 at 06:39:38PM -0700, Glenn Linderman wrote: However, also note that the sensitivity characteristic of any particular directory cannot be intuited from the sensitivity characteristic of any other directory, due to softlinks pointing to other filesystems... unless you confirm that both are one the same (type of) filesystem, which gets you back to platform specific code again, I think. Does it? I don't know of any platforms on which symlinks can't be detected. It doesn't matter whether symlinks are detected. Assumptions go pear shaped if I mount a case insensitive file system somewhere in a subdirectory of a case sensitive file system (or vice versa) You really can't tell what's going on in any other directory, based on the one you're in. I'm wondering if you can't even tell what's going on in one directory, if that directory is a logical union of several others on differing filesystems. Then again, I've not met these on any system I use. Nicholas Clark
Re: recent blead changes have introduced tainting problems
On Thu, Jul 07, 2005 at 02:39:33PM +0100, Dave Mitchell wrote:
eval_sv(123;, G_SCALAR|G_KEEPERR);
die with:
Insecure dependency in eval_sv() while running with -T
does it still fail post change 25081 ?
Ignore that, I can reproduce it now
fixed by the change below.
--
My get-up-and-go just got up and went.
Change 25094 by [EMAIL PROTECTED] on 2005/07/07 14:47:51
more taint fallout from change 24943
Affected files ...
... //depot/perl/mg.c#358 edit
... //depot/perl/scope.c#156 edit
... //depot/perl/t/op/taint.t#68 edit
Differences ...
//depot/perl/mg.c#358 (text)
@@ -1913,7 +1913,7 @@
Perl_magic_gettaint(pTHX_ SV *sv, MAGIC *mg)
{
PERL_UNUSED_ARG(sv);
-TAINT_IF(mg-mg_len 1);
+TAINT_IF((PL_localizing != 1) (mg-mg_len 1));
return 0;
}
//depot/perl/scope.c#156 (text)
@@ -170,7 +170,9 @@
Perl_save_scalar(pTHX_ GV *gv)
{
SV **sptr = GvSV(gv);
+PL_localizing = 1;
SvGETMAGIC(*sptr);
+PL_localizing = 0;
SSCHECK(3);
SSPUSHPTR(SvREFCNT_inc(gv));
SSPUSHPTR(SvREFCNT_inc(*sptr));
//depot/perl/t/op/taint.t#68 (xtext)
@@ -17,7 +17,7 @@
use File::Spec::Functions;
BEGIN { require './test.pl'; }
-plan tests = 243;
+plan tests = 244;
$| = 1;
@@ -1128,3 +1128,10 @@
test tainted $x99;
}
+# an mg_get of a tainted value during localization shouldn't taint the
+# statement
+
+{
+eval { local $0, eval '1' };
+test $@ eq '';
+}
Re: Build of mod_perl 2.0.0 fails on bleadperl - no more HvPMROOT()
Stas Bekman wrote:
[...]
If you really really feel the need to cheat then you have the choice
of these:
#define xhv_keys xiv_u.xivu_iv
typedef struct {
STRLENxhv_fill;/* how full xhv_array currently is */
STRLENxhv_max;/* subscript of last element of xhv_array */
union {
IVxivu_iv;/* integer value or pv offset */
UVxivu_uv;
void *xivu_p1;
}xiv_u;
MAGIC*xmg_magic;/* magic for scalar array */
HV*xmg_stash;/* class package */
} xpvhv_allocated;
Only xmg_magic and xmg_stash aren't needed for the operation of a
regular hash.
I've no idea what modglobal_ptr gets used for throughout the perl
codebase,
but hanging something that isn't MAGIC* from xmg_magic feels like a
bad plan.
While using xmg_magic or xmg_stash works most of the time, it fails
perl_clone at run time, where it tries to clone the member which is not of
a proper type (just a pointer cast into MAGIC*), resulting in a segfault:
#7 0xb7aaac57 in Perl_sv_dup (my_perl=0xba9bc88, sstr=0x5, param=0xb685ada0)
at sv.c:10287
#8 0xb7aaa36a in Perl_mg_dup (my_perl=0xba9bc88, mg=0xadb9608,
param=0xb685ada0)
at sv.c:10056
#9 0xb7aab3bc in Perl_sv_dup (my_perl=0xba9bc88, sstr=0xb2b20c0,
param=0xb685ada0)
at sv.c:10477
#10 0xb7aaf785 in perl_clone (proto_perl=0xaa16dd8, flags=2) at sv.c:11531
#11 0xb7895a8a in Perl_ithread_create (my_perl=0xaa16dd8, obj=0x0,
classname=0xba98910 threads, init_function=0xbd412d8, params=0xbc551b8)
at threads.xs:426
Besides the speed that I have mentioned before, there is another
requirement: the get/set should work w/o needing aTHX, therefore using a
real magic won't work.
More ideas?
Really, what we are after is the set/get mechanism used by ithreads.xs
itself, but it needs to be faster and require no aTHX. If we find one we
will be able to speed up ithreads as well. At the moment ithreads.xs does:
void Perl_ithread_set (pTHX_ ithread* thread)
{
SV* thread_sv = newSViv(PTR2IV(thread));
if(!hv_store(PL_modglobal, threads::self, 12, thread_sv,0)) {
croak(%s\n,Internal error, couldn't set TLS);
}
}
ithread* Perl_ithread_get (pTHX) {
SV** thread_sv = hv_fetch(PL_modglobal, threads::self,12,0);
if(!thread_sv) {
croak(%s\n,Internal error, couldn't get TLS);
}
return INT2PTR(ithread*,SvIV(*thread_sv));
}
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Pod::Html - correctly link to =item's on the same page
On Thu, Jul 07, 2005 at 01:07:13PM +0100, Steve Hay wrote: Yitzchak Scott-Thoennes wrote: On Tue, Jul 05, 2005 at 06:22:02PM +0100, Steve Hay wrote: So I've applied your patch, together with my test (marked as TODO since it currently fails) as change 25083. Note that it is all one test, though, so the newly fixed bit isn't actually being tested until the TODO gets resolved :-( Thanks! Here's a patch to switch the links in perlglossary back to L instead of C, plus some other minor corrections, and restoring some of Larry's original prose where I'd fiddled with it to make the C links work. podchecker emits tons of warnings and errors after applying the patch. There were no warnings or errors before :-( Any chance you could fix it up and resend? Argg. Forgot that Pod::Html is more permissive than podchecker. I'm guessing these are Lfoo where there should be L/foo. I'll fix them and resend in a while.
Re: Documenation hint: Name your arguments
On Thu, 7 Jul 2005, Michael G Schwern wrote: On Thu, Jul 07, 2005 at 09:03:54AM +0100, Steve Hay wrote: True, but Cfunction() is turned into a link to =item function by pod2html, which is often useful. If pod2man already assumes foo() is a function why not pod2html? because the code that does this should be factored out of pod2man as a pod pre-processor so that all pod parsers can use it? -- Tim Jenness JAC software http://www.jach.hawaii.edu/~timj
Smoke [5.9.3] 25094 FAIL(F) linux 2.6.12-3-686 [debian] (i686/1 cpu)
Automated smoke report for 5.9.3 patch 25094 kirk: Intel(R) Celeron(R) CPU 2.00GHz (GenuineIntel 1994MHz) (i686/1 cpu) onlinux - 2.6.12-3-686 [debian] using cc version 4.0.1 20050701 (prerelease) (Debian 4.0.0-12ubuntu2) smoketime 5 hours 17 minutes (average 39 minutes 39 seconds) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25094 Configuration (common) none --- - F F F F F F F F F F F F -Duseithreads F F F F F F -DPERL_DEBUG_COW F F F F F F -DPERL_DEBUG_COW -Duseithreads | | | | | +- LC_ALL = en_US.utf8 -DDEBUGGING | | | | +--- PERLIO = perlio -DDEBUGGING | | | +- PERLIO = stdio -DDEBUGGING | | +--- LC_ALL = en_US.utf8 | +- PERLIO = perlio +--- PERLIO = stdio Failures: [stdio/perlio/en_US.utf8] [stdio/perlio/en_US.utf8] -DDEBUGGING [stdio/perlio/en_US.utf8] -Duseithreads [stdio/perlio/en_US.utf8] -DDEBUGGING -Duseithreads [stdio/perlio/en_US.utf8] -DPERL_DEBUG_COW [stdio/perlio/en_US.utf8] -DDEBUGGING -DPERL_DEBUG_COW [stdio/perlio/en_US.utf8] -DPERL_DEBUG_COW -Duseithreads [stdio/perlio] -DDEBUGGING -DPERL_DEBUG_COW -Duseithreads ../t/op/groups.tFAILED 1 [en_US.utf8] -DDEBUGGING -DPERL_DEBUG_COW -Duseithreads ../t/op/groups.tFAILED 1 Inconsistent test results (between TEST and harness): ../lib/Memoize/t/speed.tFAILED at test 2 -- Report by Test::Smoke v1.19#716 running on perl 5.8.7 (Reporter v0.016 / Smoker v0.015)
[perl #36477] File::Basename basename() bug
[jensl - Thu Jul 07 02:54:06 2005]:
There is a bug in basename() (Module File::Basename):
According to the manpage:
basename
The basename() routine returns the first element of the list
produced by calling fileparse() with the same arguments, except that
it always quotes metacharacters in the given suffixes. It is provided
for programmer compatibility with the Unix shell command basename(1).
The bug: basename() doesn't return '/' for parameter '/'
I was about to reply that as of change 25090 this is no longer a bug
since basename() is no longer documented to return the same as the first
element of the list returned by fileparse() - it is now documented to
behave the same way as the Unix shell command basename(1), which is what
its intended purpose has always been.
However, using the Cygwin basename(1) on my Win32 system I find that:
C:\p5p\bleadperl\cygwin\bin\basename /
/
C:\p5p\bleadperl\cygwin\bin\basename \
\
whereas (using the current bleadperl @ change 25094)
File::Basename::basename() still doesn't return the same thing as the
shell command:
C:\p5p\bleadperl.\perl -MFile::Basename -e print basename('/')
C:\p5p\bleadperl.\perl -MFile::Basename -e print basename('\\')
(blank output in both cases).
Is there genuinely still a bug in File::Basename::basename(), or is it
just that Cygwin's basename(1) isn't entirely representative of what
basename(1) typically does? I'll let someone with a more traditional
Unixy system available answer that one.
Re: [perl #36477] File::Basename basename() bug
On Thu, Jul 07, 2005 at 04:17:50PM -, Steve Hay via RT wrote:
Is there genuinely still a bug in File::Basename::basename(), or is it
just that Cygwin's basename(1) isn't entirely representative of what
basename(1) typically does? I'll let someone with a more traditional
Unixy system available answer that one.
Its a bug. Patch attached.
And I found another bug, but I will keep you in suspense until my next
patch!
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
--- lib/File/Basename.pm2005/07/07 21:04:45 1.1
+++ lib/File/Basename.pm2005/07/07 21:09:11
@@ -206,9 +206,13 @@
sub basename {
- my($name) = shift;
- _strip_trailing_sep($name);
- (fileparse($name, map(\Q$_\E,@_)))[0];
+ my($path) = shift;
+
+ _strip_trailing_sep($path);
+ my($basename, $dirname) = fileparse( $path, map(\Q$_\E,@_) );
+ $basename = $dirname unless length $basename;
+
+ return $basename;
}
--- lib/File/Basename.t 2005/07/07 20:55:38 1.1
+++ lib/File/Basename.t 2005/07/07 21:14:20
@@ -5,7 +5,7 @@
@INC = '../lib';
}
-use Test::More tests = 57;
+use Test::More tests = 60;
BEGIN { use_ok 'File::Basename' }
@@ -26,7 +26,6 @@
is(basename('/arma/virumque.cano'), 'virumque.cano');
is(dirname ('/arma/virumque.cano'), '/arma');
is(dirname('arma/'), '.');
-is(dirname('/'), '/');
}
@@ -131,6 +130,18 @@
}
+### rt.cpan.org 36477
+{
+fileparse_set_fstype('Unix');
+is(dirname('/'), '/');
+is(basename('/'), '/');
+
+fileparse_set_fstype('DOS');
+is(dirname('\\'), '\\');
+is(basename('\\'), '\\');
+}
+
+
### Test tainting
{
# The empty tainted value, for tainting strings
@@ -150,6 +161,7 @@
1;
}
+fileparse_set_fstype 'Unix';
ok tainted(dirname($TAINT.'/perl/lib//'));
ok all_tainted(fileparse($TAINT.'/dir/draft.book7','\.book\d+'));
}
Re: [PATCH] Further lies in the File::Basename docs
On Thu, Jul 07, 2005 at 04:02:07PM +0100, Nicholas Clark wrote: It doesn't matter whether symlinks are detected. Assumptions go pear shaped if I mount a case insensitive file system somewhere in a subdirectory of a case sensitive file system (or vice versa) That why we ask for the mount points. Things can potentially go wrong when File::System::Spec is used to just probe the cwd without knowing where the mount points are. The user is free to assume whatever they want from the characteristics of the cwd, and most of the time its probably perfectly correct, but File::System::Spec does not make the assumption. When I can see this going wrong in the field is if probing is done very high up in the directory tree like in / or /tmp. However, given that currently there are NO utilities for probing file system characteristics and that we blindly assume them based on $^O this is nothing but a step up. You really can't tell what's going on in any other directory, based on the one you're in. I'm wondering if you can't even tell what's going on in one directory, if that directory is a logical union of several others on differing filesystems. Then again, I've not met these on any system I use. Please, don't give me nightmares. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [PATCH] Further lies in the File::Basename docs
On Thu, Jul 07, 2005 at 10:25:36AM -0700, Glenn Linderman wrote: Yes, provision for some level of change of the cached information is good, even necessary. Under what conditions would flushing take place? Ever automatically? When a system is reconfigured, that is when an additional probe would be needed. It'll be manual. About the only way I can see making it automatic is to have something which can automatically determine the current mount points and file types (say by using `df -T`) and recognize that they have changed. But this gets system specific. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: [PATCH] Pod::Html - correctly link to =item's on the same page
On Thu, Jul 07, 2005 at 09:45:51AM -0700, Yitzchak Scott-Thoennes wrote: On Thu, Jul 07, 2005 at 01:07:13PM +0100, Steve Hay wrote: Yitzchak Scott-Thoennes wrote: On Tue, Jul 05, 2005 at 06:22:02PM +0100, Steve Hay wrote: So I've applied your patch, together with my test (marked as TODO since it currently fails) as change 25083. Note that it is all one test, though, so the newly fixed bit isn't actually being tested until the TODO gets resolved :-( Thanks! Here's a patch to switch the links in perlglossary back to L instead of C, plus some other minor corrections, and restoring some of Larry's original prose where I'd fiddled with it to make the C links work. podchecker emits tons of warnings and errors after applying the patch. There were no warnings or errors before :-( Any chance you could fix it up and resend? Argg. Forgot that Pod::Html is more permissive than podchecker. I'm guessing these are Lfoo where there should be L/foo. I'll fix them and resend in a while. Here's another try; passes podchecker this time :) There are a few remaining problems; Pod::Html generates the following broken links: file://c|\perl\html/lib/strict.html#strict_refs file://c|\perl\html/lib/strict.html#strict_subs file://c|\perl\html/pod/perlfaq2.html#what_modules_and_extensions_are_available_for_perl_what_is_cpan_what_does_cpane_sol_srce_sol_mean file://c|\perl\html/pod/perlop.html#tre_sol_searchliste_sol_replacementliste_sol_cds #standard_ie_sol_o The first two are trying to link to =item Cstrict refs and =item Cstrict subs in strict.pm, but the C on the =item line makes Pod::Html not find it, so it doesn't correctly link as #item_strict_subs and #item_strict_refs. The last three should work according to my understanding of perlpod.pod, but apparently Pod::Html doesn't translate Esol to / before creating the link name. Two other infelicities are unfortunate links that *do* work: hexadecimal: Cf links to file://c|\perl\html/pod/perlguts.html#item_f regular file: C-f links to file://c|\perl\html/pod/perlrun.html#item__2df I'm going to leave this all as is for now, and maybe get back to it someday; Steve, if you understand Pod::Html enough to suggest a fix for the Esol problem, I will try to at least see if your fix makes sense.
Re: [PATCH] Pod::Html - correctly link to =item's on the same page
On Thu, Jul 07, 2005 at 03:05:00PM -0700, Yitzchak Scott-Thoennes wrote: On Thu, Jul 07, 2005 at 09:45:51AM -0700, Yitzchak Scott-Thoennes wrote: On Thu, Jul 07, 2005 at 01:07:13PM +0100, Steve Hay wrote: Yitzchak Scott-Thoennes wrote: On Tue, Jul 05, 2005 at 06:22:02PM +0100, Steve Hay wrote: So I've applied your patch, together with my test (marked as TODO since it currently fails) as change 25083. Note that it is all one test, though, so the newly fixed bit isn't actually being tested until the TODO gets resolved :-( Thanks! Here's a patch to switch the links in perlglossary back to L instead of C, plus some other minor corrections, and restoring some of Larry's original prose where I'd fiddled with it to make the C links work. podchecker emits tons of warnings and errors after applying the patch. There were no warnings or errors before :-( Any chance you could fix it up and resend? Argg. Forgot that Pod::Html is more permissive than podchecker. I'm guessing these are Lfoo where there should be L/foo. I'll fix them and resend in a while. Here's another try; passes podchecker this time :) And now with attachment :) glosupd.patch.gz Description: application/gunzip
Re: Documenation hint: Name your arguments
On Wed, Jul 06, 2005 at 11:17:34AM -0700, Russ Allbery wrote: Steve Hay [EMAIL PROTECTED] writes: I have always favoured I$variable because I used to be recommended for variables in perlpod.pod (used for emphasis or variables), but I see that change 12542 reworded the description for I as used for emphasis and parameters and now gives the example redo ILABEL. Yeah, the intention was, I believe, metasyntactic variables. (Which I still think should be a completely separate POD command.) Such as R from http://search.cpan.org/~arandal/Pod-PseudoPod-0.11/lib/Pod/PseudoPod/Tutorial.pod#Inline_Character_Tagging ? Still makes me think this was argued at some point and you lost.
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 11:11:19AM -1000, Joshua Hoblitt wrote: On Wed, Jul 06, 2005 at 09:40:11AM -0700, Michael G Schwern wrote: On Wed, Jul 06, 2005 at 11:29:21AM -0500, Andy Lester wrote: On Wed, Jul 06, 2005 at 09:22:32AM -0700, Michael G Schwern ([EMAIL PROTECTED]) wrote: * Simplify the what's case-insensitive docs. Its just all non-Unix. What about Mac OS X running HFS? Or Linux running FAT32? Or OS X running UFS (which is case sensitive)? The whole idea is basically doomed because we assume the underlying file system type based on the operating system. But we make this assumption all over the place in the Perl core and File::Basename is not the place to start fixing it. Instead of trying to determine which filesystem your on (is there any reasonable way of evening doing that?) why not just test for case sensitivity when the module is loaded with a BEGIN block? Granted this is ugly, and granted you would likely only be able to test the file system that a dir created by File::Temp::tempdir() lives on, but it should be fairly portable. That's not going to work on a file system that's mounted read-only. I'd say that for systems that have a /proc/mounts file that lists the file type, the lookup table based on OS should be replaced by a lookup table based on filesystem. Abigail pgp8jUYV4oXwa.pgp Description: PGP signature
Re: [perl #36473] s/PATTERN/func()/em leaks /m into func().
On Wed, Jul 06, 2005 at 10:34:33PM -, abigail @ abigail. nl wrote: I've confirmed the bug to be present in 5.000, 5.004_0[45], 5.005_0x, 5.6.x and 5.8.x, including 5.8.7. However, the bug isn't present in any of the 5.9.x versions of perl. I think this was fixed by the removal of the long-deprecated $*.
Re: [PATCH] Further lies in the File::Basename docs
On Fri, Jul 08, 2005 at 12:12:44AM +0200, Abigail wrote: That's not going to work on a file system that's mounted read-only. Yitzak outlined a way to determine case-sensitivity in a read-only fashion. It basically boils down to: 1. Find a file or directory with [A-Za-z] in it. 2. Change the case of a few of those letters. 3. Check to see if it exists. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: Documenation hint: Name your arguments
Yitzchak Scott-Thoennes [EMAIL PROTECTED] writes: On Wed, Jul 06, 2005 at 11:17:34AM -0700, Russ Allbery wrote: Yeah, the intention was, I believe, metasyntactic variables. (Which I still think should be a completely separate POD command.) Such as R from http://search.cpan.org/~arandal/Pod-PseudoPod-0.11/lib/Pod/PseudoPod/Tutorial.pod#Inline_Character_Tagging ? Yup, that would work. I would tend to use M, but I don't really care. Still makes me think this was argued at some point and you lost. Well, the problem is more that the author of Pod::Simple ran out of time to work on the package before putting out a release that added the required support that I need to release the next version of podlators, which is Pod::Simple-based and has been ready for nine months except that it still needs a patch that he said would be in the next release of Pod::Simple. And everything else is stalled on that, since Pod::Simple added the necessary infrastructure to add new inline sequences. Beyond that, I think it's just a simple matter of agreeing on what letter to use and then starting to implement it in the translators. Maybe I should just release the new version of podlators, including the required patch, and tell people to apply it to Pod::Simple before installing. :/ -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Smoke [5.9.3] 25093 FAIL(F) openbsd 3.7 (macppc/1 cpu)
Op een mooie zomerdag (Friday 08 July 2005 01:03),schreef Abe Timmerman: Automated smoke report for 5.9.3 patch 25093 bobby.ztreet.xs4all.nl: 7400 (Revision 0x209) (400 MHz) (macppc/1 cpu) onopenbsd - 3.7 using cc version 3.3.5 (propolice) smoketime 7 hours 26 minutes (average 55 minutes 50 seconds) Summary: FAIL(F) ... Failures: (common-args) none ... The t/io/*.t failures (on all mij bsd/darwin systems) do not show up if I run the smoke script directly, they only show up when the smoke-scripts are run from a shell-script that loops over them. Is this a BSD issue or a perl issue? The array failures are specific to this system... [stdio/perlio] -Duse64bitint [stdio/perlio] -DDEBUGGING -Duse64bitint ../lib/Tie/Array/std.t..FAILED 85 ../t/io/dup.t...FAILED 15-16 ../t/io/open.t..FAILED 93 ../t/op/array.t.FAILED 85 From the smoke-log: Extending failures with harness: ../lib/Tie/Array/std.t ../t/io/dup.t ../t/io/open.t ../t/op/array.t # Failed at test.pl line 249 # got 'Modification of non-creatable array value attempted, subscript 0 at (eval 9) line 1. # ' # expected /(?-xism:Modification of non-creatable array value attempted, subscript -1)/ # Failed at ../t/io/dup.t line 99 # Failed at ../t/io/dup.t line 100 # got undef # expected '0' # Failed at ../t/io/open.t line 237 # Failed at test.pl line 249 # got 'Modification of non-creatable array value attempted, subscript 0 at (eval 9) line 1. # ' # expected /(?-xism:Modification of non-creatable array value attempted, subscript -1)/ Failed 4/4 test scripts, 0.00% okay. 5/356 subtests failed, 98.60% okay. HTH + Good luck, Abe -- [About a VMS specific path] G.Berry Can I point at you if anything other than this goes wrong? ;-) Everyone else will, so I don't see why you shouldn't. -- Nicholas Clark on p5p @ 2004-07-20
[PATCH] basename() and suffixes
basename(1) sez:
The suffix is not stripped if it is identical to the remaining characters
in string.
Which our basename() does not do. This patch makes it do.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
--- lib/File/Basename.pm2005/07/07 21:10:58 1.2
+++ lib/File/Basename.pm2005/07/07 22:34:26
@@ -157,9 +157,9 @@
}
- my($tail, $suffix);
+ my $tail = '';
+ my $suffix = '';
if (@suffices) {
-$tail = '';
foreach $suffix (@suffices) {
my $pat = ($igncase ? '(?i)' : '') . ($suffix)\$;
if ($basename =~ s/$pat//s) {
@@ -170,7 +170,7 @@
}
# Ensure taint is propgated from the path to its pieces.
- $tail .= $taint if defined $tail; # avoid warning if $tail == undef
+ $tail .= $taint;
wantarray ? ($basename .= $taint, $dirpath .= $taint, $tail)
: ($basename .= $taint);
}
@@ -208,9 +208,24 @@
sub basename {
my($path) = shift;
+ # From BSD basename(1)
+ # The basename utility deletes any prefix ending with the last slash `/'
+ # character present in string (after first stripping trailing slashes)
_strip_trailing_sep($path);
- my($basename, $dirname) = fileparse( $path, map(\Q$_\E,@_) );
- $basename = $dirname unless length $basename;
+
+ my($basename, $dirname, $suffix) = fileparse( $path, map(\Q$_\E,@_) );
+
+ # From BSD basename(1)
+ # The suffix is not stripped if it is identical to the remaining
+ # characters in string.
+ if( length $suffix and !length $basename ) {
+ $basename = $suffix;
+ }
+
+ # Ensure that basename '/' == '/'
+ if( !length $basename ) {
+ $basename = $dirname;
+ }
return $basename;
}
--- lib/File/Basename.t 2005/07/07 21:10:39 1.2
+++ lib/File/Basename.t 2005/07/07 22:37:03
@@ -5,7 +5,7 @@
@INC = '../lib';
}
-use Test::More tests = 60;
+use Test::More tests = 64;
BEGIN { use_ok 'File::Basename' }
@@ -139,6 +139,17 @@
fileparse_set_fstype('DOS');
is(dirname('\\'), '\\');
is(basename('\\'), '\\');
+}
+
+
+### basename(1) sez: The suffix is not stripped if it is identical to the
+### remaining characters in string
+{
+fileparse_set_fstype('Unix');
+is(basename('.foo'), '.foo');
+is(basename('.foo', '.foo'), '.foo');
+is(basename('.foo.bar', '.foo'), '.foo.bar');
+is(basename('.foo.bar', '.bar'), '.foo');
}
Re: Scalar leaked in 'local $0' under ithreads + taint mode
On Thu, Jul 07, 2005 at 01:56:39PM +0100, Steve Hay wrote: Hmm. I just retried this with current blead and I find that it (apparently) works OK with a debug build, but crashes with a release build. I can't get it to crash on either type of build (Linux). Fortunately, release builds on Win32 have debugging symbols anyway (since they are stored in separate files), so I am able to get a stack trace: win32_checkTLS(interpreter * 0x73204441) line 57 PerlEnvGetenv(IPerlEnv * 0x01857670, const char * 0x280b79b8 `string') line 454 + 19 bytes PerlIO_debug(const char * 0x280b79e0 `string') line 461 + 14 bytes PerlIO_clone(interpreter * 0x018b2ad4, interpreter * 0x00234494, clone_params * 0x0140fc80) line 643 perl_clone_using(interpreter * 0x00234494, unsigned long 6, IPerlMem * 0x0185761c, IPerlMem * 0x01857638, IPerlMem * 0x01857654, IPerlEnv * 0x01857670, IPerlStdIO * 0x018576a8, IPerlLIO * 0x01857744, IPerlDir * 0x018577ac, IPerlSock * 0x018577d8, IPerlProc * 0x01857888) line 11383 perl_clone_host(interpreter * 0x00234494, unsigned long 6) line 315 + 67 bytes perl_clone(interpreter * 0x00234494, unsigned long 6) line 11183 + 11 bytes Perl_ithread_create(interpreter * 0x, sv * 0x, char * 0x018325e4, sv * 0x002354cc, sv * 0x01828c64) line 424 + 8 bytes XS_threads_new(interpreter * 0x0002, cv * 0x018a83f4) line 687 + 32 bytes Perl_pp_entersub(interpreter * 0x01234494) line 2789 Perl_runops_standard(interpreter * 0x00234494) line 38 + 45 bytes S_run_body(interpreter * 0x00234494, long 1) line 2231 + 10 bytes perl_run(interpreter * 0x00234494) line 2160 + 10 bytes RunPerl(int 3, char * * 0x00232440, char * * 0x00232d08) line 217 + 6 bytes PERL! mainCRTStartup + 227 bytes KERNEL32! 77e8141a() threads-new() tries to clone an intepreter; this calls PerlIO_clone(), which calls PerlIO_debug(), which tries to get the value (if any) of the env var PERLIO_DEBUG. At this point it jumps into windows-specific code, where it then crashes. Does it still fail after change 25094? I'm pretty much clutching at straws here, but that does hapen to fix an unrelated bug associated with doing 'local $0' -- Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. -- Dennis - Monty Python and the Holy Grail.
Re: Smoke [5.9.3] 25093 FAIL(F) openbsd 3.7 (macppc/1 cpu)
On Fri, Jul 08, 2005 at 12:33:21AM +0200, Abe Timmerman wrote: Op een mooie zomerdag (Friday 08 July 2005 01:03),schreef Abe Timmerman: ... The t/io/*.t failures (on all mij bsd/darwin systems) do not show up if I run the smoke script directly, they only show up when the smoke-scripts are run from a shell-script that loops over them. Is this a BSD issue or a perl issue? Beside a few initial bumps with OpenBSD 3.7, I've not had any major issues with the smokes. In fact, my last failed smoke was about three weeks ago. Steve Peters [EMAIL PROTECTED]
Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
On Tue, Jun 07, 2005 at 04:28:08PM -, Nicholas Clark wrote:
./perl -Ilib -we '$term = \xe9; $target = \xe9\x{100}; chop $target;
$target =~ /$term/i'
Malformed UTF-8 character (unexpected non-continuation byte 0x00, immediately
after start byte 0xe9) in pattern match (m//) at -e line 1.
it turns out perl is totally borked for
$utf8 =~ /latin1/i
and
$latin1 =~ /$utf8/i
unless all the chars happen to be 0x7f.
The patch below fixes the first case: the fault was in ibcmp_utf8(),
which was calling to_utf8_fold() without first converting the char to
utf8.
The second case fails in S_find_byclass() in regexec.c:
while (s = e) {
if ( (*(U8*)s == c1 || *(U8*)s == c2)
(ln == 1 || !(OP(c) == EXACTF
? ibcmp(s, m, ln)
: ibcmp_locale(s, m, ln)))
(norun || regtry(prog, s)) )
goto got_it;
s++;
}
where it calls ibcmp() but s is a pointer to a latin1 while m is pointer
to a utf8 char. I don't really understand this code well enough to feel
confident fixing it. In fact I'm not even totally confident in my fix for
the first case, hence I'm Ccing everyone's Favourite Finn.
Dave.
--
But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged. -- Lady Croom - Arcadia
Change 25095 by [EMAIL PROTECTED] on 2005/07/08 01:43:24
[perl #36207] UTF8/Latin 1/i regexp Malformed character warning
$utf8 =~ /latin/i didn't match.
Also added TODO for $latin =~ /utf8/i which also fails
Affected files ...
... //depot/perl/t/op/pat.t#222 edit
... //depot/perl/utf8.c#239 edit
Differences ...
//depot/perl/t/op/pat.t#222 (xtext)
@@ -6,7 +6,7 @@
$| = 1;
-print 1..1178\n;
+print 1..1180\n;
BEGIN {
chdir 't' if -d 't';
@@ -3364,4 +3364,14 @@
my $psycho=join |,@normal,map chr $_,255..2;
ok(('these'=~/($psycho)/) $1 eq 'these','Pyscho');
}
-# last test 1178
+
+# [perl #36207] mixed utf8 / latin-1 and case folding
+
+{
+my $u = \xe9\x{100};
+chop $u;
+ok($u =~ /\xe9/i, utf8/latin);
+ok(\xe9 =~ /$u/i, # TODO latin/utf8);
+}
+
+# last test 1180
//depot/perl/utf8.c#239 (text)
@@ -2037,7 +2037,7 @@
if (u1)
to_utf8_fold(p1, foldbuf1, foldlen1);
else {
- natbuf[0] = *p1;
+ uvuni_to_utf8(natbuf, (UV) NATIVE_TO_UNI(((UV)*p1)));
to_utf8_fold(natbuf, foldbuf1, foldlen1);
}
q1 = foldbuf1;
@@ -2047,7 +2047,7 @@
if (u2)
to_utf8_fold(p2, foldbuf2, foldlen2);
else {
- natbuf[0] = *p2;
+ uvuni_to_utf8(natbuf, (UV) NATIVE_TO_UNI(((UV)*p2)));
to_utf8_fold(natbuf, foldbuf2, foldlen2);
}
q2 = foldbuf2;
