Steve Peters:
perl -we '$file=X; open my $fh, $file;'
Parentheses missing around my list at -e line 1.
The warning is inappropriate in this context.
This can be prevented by simply putting a () around the $fh so that
Perl scopes the my correctly.
I don't
Yitzchak Scott-Thoennes wrote:
I agree with the sentiment, but think it would be worth it (perhaps in
conjuction with a short warning in perlfunc/exists that exists on @_
or @DB::args may not work).
The only complete fix I see would be to also make av_reify replace all
PL_sv_undefs with new
On Wed, Jun 08, 2005 at 03:37:45AM -0400, Mark Jason Dominus wrote:
Steve Peters:
perl -we '$file=X; open my $fh, $file;'
Parentheses missing around my list at -e line 1.
The warning is inappropriate in this context.
This can be prevented by simply
On Tue, Jun 07, 2005 at 03:11:31PM +0100, Nicholas Clark wrote:
Is this patch (or something close) worth applying?
Looks like a good idea to me.
On Wed, Jun 08, 2005 at 10:06:28AM +0200, Rafael Garcia-Suarez wrote:
Yitzchak Scott-Thoennes wrote:
I agree with the sentiment, but think it would be worth it (perhaps in
conjuction with a short warning in perlfunc/exists that exists on @_
or @DB::args may not work).
The only complete
Yitzchak Scott-Thoennes wrote:
On Wed, Jun 08, 2005 at 10:06:28AM +0200, Rafael Garcia-Suarez wrote:
Yitzchak Scott-Thoennes wrote:
I agree with the sentiment, but think it would be worth it (perhaps in
conjuction with a short warning in perlfunc/exists that exists on @_
or @DB::args
José Pedro Oliveira wrote:
When the mrtg cron job runs under the SELinux strict policy
(this problem doesn't occur with the targeted policy), it runs
in a restricted domain that doesn't allow acces to the root
homedir (the cron job uses the root account).
When this happen the variable
Andy Lester wrote:
This patch refactors some repeated code into macros, and throws in an
assertion to make sure that the UTF8 classes have been loaded succesfully,
all in the name of cleaning up a whole bunch of lint and GCC warnings.
Thanks, applied as change #24754.
On Wed, Jun 08, 2005 at 11:28:01AM +0200, Rafael Garcia-Suarez wrote:
Yitzchak Scott-Thoennes wrote:
On Wed, Jun 08, 2005 at 10:06:28AM +0200, Rafael Garcia-Suarez wrote:
Yitzchak Scott-Thoennes wrote:
I agree with the sentiment, but think it would be worth it (perhaps in
conjuction
On Tue, Jun 07, 2005 at 06:54:40PM -0700, Yitzchak Scott-Thoennes wrote:
I agree with the sentiment, but think it would be worth it (perhaps in
conjuction with a short warning in perlfunc/exists that exists on @_
or @DB::args may not work).
But it can happen in other circumstances too. Eg XS
Automated smoke report for 5.9.3 patch 24745
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 58 minutes (average 1 hour 59 minutes)
Summary: FAIL(F)
O = OK F = Failure(s), extended
[stmpeters - Wed Jun 08 03:58:28 2005]:
[ysth - Wed Jun 08 01:08:32 2005]:
On Wed, Jun 08, 2005 at 03:37:45AM -0400, Mark Jason Dominus wrote:
Steve Peters:
perl -we '$file=X; open my $fh, $file;'
Parentheses missing around my list at -e
Steve Peters via RT wrote:
This ticket has been reopened, but I not really sure why? Can you explain?
Oops! I forgot to copy p5p on the reply. Can you give an explanation of why
this warning is
inappropriate please?
because the code is appropriately parsed by perl.
This is one
On Wed, 8 Jun 2005 14:19:39 +0200, Rafael Garcia-Suarez
[EMAIL PROTECTED] wrote:
Steve Peters via RT wrote:
This ticket has been reopened, but I not really sure why? Can you
explain?
Oops! I forgot to copy p5p on the reply. Can you give an explanation of
why this warning
H.Merijn Brand wrote:
another rather annoying one is
pc09:/home/merijn 101 perl -we'$x=foo\nbar;-f $x and die file'
Unsuccessful stat on filename containing newline at -e line 1.
pc09:/home/merijn 102
(changing Subject:)
Do you often have filenames that contain \n ?
On Wed, Jun 08, 2005 at 02:40:55PM +0200, Rafael Garcia-Suarez wrote:
H.Merijn Brand wrote:
another rather annoying one is
pc09:/home/merijn 101 perl -we'$x=foo\nbar;-f $x and die file'
Unsuccessful stat on filename containing newline at -e line 1.
pc09:/home/merijn 102
On Wed, 8 Jun 2005 14:40:55 +0200, Rafael Garcia-Suarez
[EMAIL PROTECTED] wrote:
H.Merijn Brand wrote:
another rather annoying one is
pc09:/home/merijn 101 perl -we'$x=foo\nbar;-f $x and die file'
Unsuccessful stat on filename containing newline at -e line 1.
pc09:/home/merijn 102
On Wed, Jun 08, 2005 at 02:19:39PM +0200, Rafael Garcia-Suarez wrote:
Steve Peters via RT wrote:
This ticket has been reopened, but I not really sure why? Can you
explain?
Oops! I forgot to copy p5p on the reply. Can you give an explanation of
why this warning is
Steve Peters wrote:
Since the heuristics of this warning seem to be too simplistic for the
situation its trying to handle, is this warning needed?
No, I think it's still very useful for code like :
my $foo, bar;
[EMAIL PROTECTED] - Wed Jun 08 06:18:40 2005]:
Steve Peters wrote:
Since the heuristics of this warning seem to be too simplistic for the
situation its trying to handle, is this warning needed?
No, I think it's still very useful for code like :
my $foo, bar;
In that
Here's some consting and localizing and reindenting of pp_pack.c
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Index: pp_pack.c
===
--- pp_pack.c (revision 522)
+++ pp_pack.c (working copy)
@@ -2319,7
Automated smoke report for 5.9.3 patch 24744
mccoy.peters.homeunix.org: Intel Pentium III (GenuineIntel 686-class, 512KB
L2 cache) (i386/1 cpu)
onopenbsd - 3.7
using cc version 3.3.5 (propolice)
smoketime 8 hours 33 minutes (average 1 hour 4 minutes)
Summary: FAIL(F)
O =
# New Ticket Created by Salvador Fandio
# Please include the string: [perl #36211]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36211
To: [EMAIL PROTECTED]
Subject: local @a inside eval
Cc: [EMAIL PROTECTED]
# New Ticket Created by Robert Norris
# Please include the string: [perl #36213]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36213
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #36214]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36214
This is a success report for perl from [EMAIL PROTECTED],
generated with the
# New Ticket Created by Cosimo Streppone
# Please include the string: [perl #36216]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36216
This is a success report for perl from [EMAIL PROTECTED],
generated with the
# New Ticket Created by fredaa elder
# Please include the string: [perl #36217]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36217
Dear Perl people:
I got very puzzled with the following situation:
using '==' for
Hi,
I reported bug #36211 via perlbug but it is not showing here
(well, here at nntp://nntp.per.org/perl.perl5.porters), and I
believe it's a serious one that shouldn't go unnoticed.
Cheers,
- Salvador.
On Tue, 2005-06-07 at 23:04 +, Steve Peters via RT wrote:
perl -we '$file=X; open my $fh, $file;'
Parentheses missing around my list at -e line 1.
The warning is inappropriate in this context.
A workaround is to write:
perl -we '$file=X;
On Wed, Jun 08, 2005 at 12:01:32AM -, Salvador Fandiño wrote:
$#a gets corrupted in this code:
perl -e 'for (1,2) {eval { local @a; print $#a\n; @a=(1..4) } }'
-1
255
The bug appears to present even if the eval is replaced with a bare
block, but not if the block is removed altogether.
On Wed, Jun 08, 2005 at 08:43:05PM +0100, Dave Mitchell wrote:
On Wed, Jun 08, 2005 at 12:01:32AM -, Salvador Fandiño wrote:
$#a gets corrupted in this code:
perl -e 'for (1,2) {eval { local @a; print $#a\n; @a=(1..4) } }'
-1
255
The bug appears to present even if the eval is
On Wed, Jun 08, 2005 at 10:11:08PM +0200, Paul Johnson wrote:
The bug appears to present even if the eval is replaced with a bare
block, but not if the block is removed altogether. The second time round
the loop, the magic $#a SV proxy that's pushed onto the stack is supposed
to have a
On Wed, Jun 08, 2005 at 07:06:07AM -0400, Garry Williams wrote:
On Tue, 2005-06-07 at 23:04 +, Steve Peters via RT wrote:
perl -we '$file=X; open my $fh, $file;'
Parentheses missing around my list at -e line 1.
The warning is inappropriate in this
On Wed, Jun 08, 2005 at 01:41:12PM -, Steve Peters via RT wrote:
[EMAIL PROTECTED] - Wed Jun 08 06:18:40 2005]:
Steve Peters wrote:
Since the heuristics of this warning seem to be too simplistic for the
situation its trying to handle, is this warning needed?
No, I think
On Wed, Jun 08, 2005 at 09:09:14AM -, fredaa elder wrote:
I got very puzzled with the following situation:
using '==' for numeric equality on string 23.456 7
/s
versus the number 23.456, it tests OK/TRUE while I
would
think it should be FALSE.
Its true because the numification of
Automated smoke report for 5.9.3 patch 24765
TANGAROA.uk.radan.com: Intel(R) Pentium(R) 4 CPU 2.00GHz(~1992 MHz) (x86/1 cpu)
onMSWin32 - WinXP/.Net SP1
using cl version 12.00.8804
smoketime 3 hours 56 minutes (average 9 minutes 52 seconds)
Summary: FAIL(FM)
O = OK F =
Hmm. mjd's response doesn't seem to have reopened the ticket, though.
Why not?
Because we'd end up with a *ton* of re-opened tickets if we had that
activated. Discussion often goes on after the bug has been
(correctly) marked resolved.
-R
The attached patch does data pointer - function pointer casting
a bit differently than my earlier attempts at it, which tunneled
the pointers through a union. There's an easier way to do it which
feels slightly less unclean (and avoids assigning the value to a
temp slot), by doing a double cast
38 matches
Mail list logo
