'no strict "refs"' considered harmful?

[Jeff 'japhy' Pinyan]

That sounds sillier than my concern actually is.  I noticed today (I don't 
know why today, and not the days before when I've seen this common idiom) 
that a person creating dynamic functions did the following:


  use strict;

  # ...

  for (@function_names) {
no strict 'refs';
*$_ = sub {
  # ...
};
  }

I've seen that in various perldocs, and it seems to be a common practice 
when it comes to defining dynamically named functions.  But there's a very 
specific flaw inherent here.


  use strict;

  my @method_names = qw( foobar quux xyzzy );

  for my $m (@method_names) {
no strict 'refs';
*{ "ClassName::$m" } = sub {
  my ($self, $val) = @_;
  $self->{$m} = $val;
};
  }

This sets up a bunch of methods for some object of class ClassName.  The 
idea being you can now say


  my $obj = ClassName->new;
  $obj->foobar(10);

and set $obj->{foobar} to 10.  But what if you slip up and write

  ClassName->foobar(10);

As Scooby-Doo would say, "RUH ROH!"  We turned off strict's grip on 
references, and now we've accidentally worked with a symbolic reference. 
And strict won't mind a bit!


Although it looks a bit clunkier, I would suggest changing the idiom to

  for (...) {
my $code = sub { ... };
no strict 'refs';
*$_ = $code;
  }

--
Jeff "japhy" Pinyan %  How can we ever be the sold short or
RPI Acacia Brother #734 %  the cheated, we who for every service
http://japhy.perlmonk.org/  %  have long ago been overpaid?
http://www.perlmonks.org/   %-- Meister Eckhart

Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!

[Michael G Schwern]

So it sounds like the resolution for this bug is to document that sort
uses aliases like grep does.  I've stolen the wording from grep.

-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick
--- pod/perlfunc.pod2005/07/24 02:57:16 1.2
+++ pod/perlfunc.pod2005/07/24 02:58:42
@@ -4926,6 +4926,12 @@
 When C is in effect, C sorts LIST according to the
 current collation locale.  See L.
 
+sort returns aliases into the original list, much as a for loop's
+index variable aliases the list elements.  That is, modifying an
+element of a list returned by sort (for example, in a "foreach", "map"
+or "grep") actually modifies the element in the original list.  This
+is usually something to be avoided when writing clear code.
+
 Perl 5.6 and earlier used a quicksort algorithm to implement sort.
 That algorithm was not stable, and I go quadratic.  (A I sort
 preserves the input order of elements that compare equal.  Although

[PATCH perlfunc.pod/crypt] crypt() digests, not encrypts

[Michael G Schwern]

Attached is a patch which replaces the term "encrypt" in the perlfunc/crypt
documentation with "digest" or "hash" which more accurately describes what
crypt does.  I also added in some better explaination of what crypt does and
what one-way hashing is useful for.

I tried to avoid "hash" where possible to avoid confusion with the hash
data structure.  Even though they are related it would just confuse things.

Below is the new documentation after patching.


=item crypt PLAINTEXT,SALT 
 
Digests a string exactly like the crypt(3) function in the C library 
(assuming that you actually have a version there that has not been 
extirpated as a potential munition). 
 
crypt() is a one-way hash function.  The PLAINTEXT and SALT is turned 
into a short, fixed length string, called a digest, which is returned. 
The same PLAINTEXT and SALT will always return the same string, but 
there is no (known) way to get the original PLAINTEXT from the hash. 
The SALT is visible as part of the digest.  Small changes in the 
PLAINTEXT will result in large changes in the hash. 
 
There is no decrypt function.  This function isn't all that useful for 
cryptography (for that, see your nearby CPAN mirror) and the name 
"crypt" is a bit of a misnomer.  Instead it is primarily used to check 
if two pieces of text are the same without having to transmit or store 
the text itself.  An example is checking if a correct password is 
given.  The digest of the password is stored, not the password itself. 
The user types in a password which is crypt()'d with the same salt as 
the stored digest.  If the two digests match the password is correct. 
 
When verifying an existing digest string you should use the digest as 
the salt (like C).  This allows 
your code to work with the standard L and with more 
exotic implementations.  In other words, do not assume anything about 
the returned string itself, or how many bytes in the digest matter. 
 
Traditionally the result is a string of 13 bytes: two first bytes of 
the salt, followed by 11 bytes from the set C<[./0-9A-Za-z]>, and only 
the first eight bytes of the digest string mattered, but alternative 
hashing schemes (like MD5), higher level security schemes (like C2), 
and implementations on non-UNIX platforms may produce different 
strings. 
 
When choosing a new salt create a random two character string whose 
characters come from the set C<[./0-9A-Za-z]> (like C).  This set of 
characters is just a recommendation; the characters allowed in 
the salt depend solely on your system's crypt library, and Perl can't 
restrict what salts C accepts. 
 
Here's an example that makes sure that whoever runs this program knows 
their own password: 

$pwd = (getpwuid($<))[1]; 
 
system "stty -echo"; 
print "Password: "; 
chomp($word = ); 
print "\n"; 
system "stty echo"; 
 
if (crypt($word, $pwd) ne $pwd) { 
die "Sorry...\n"; 
} else { 
print "ok\n"; 
} 
 
Of course, typing in your own password to whoever asks you 
for it is unwise. 
 
The L function is unsuitable for hashing large quantities 
of data, not least of all because you can't get the information 
back.  Look at the F and F directories 
on your favorite CPAN mirror for a slew of potentially useful 
modules. 
 
If using crypt() on a Unicode string (which I has 
characters with codepoints above 255), Perl tries to make sense 
of the situation by trying to downgrade (a copy of the string) 
the string back to an eight-bit byte string before calling crypt() 
(on that copy).  If that works, good.  If not, crypt() dies with 
C. 


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
--- pod/perlfunc.pod2005/07/24 00:04:05 1.1
+++ pod/perlfunc.pod2005/07/24 00:24:01
@@ -885,31 +885,38 @@
 
 =item crypt PLAINTEXT,SALT
 
-Encrypts a string exactly like the crypt(3) function in the C library
+Digests a string exactly like the crypt(3) function in the C library
 (assuming that you actually have a version there that has not been
-extirpated as a potential munition).  This can prove useful for checking
-the password file for lousy passwords, amongst other things.  Only the
-guys wearing white hats should do this.
-
-Note that L is intended to be a one-way function, much like
-breaking eggs to make an omelette.  There is no (known) corresponding
-decrypt function (in other words, the crypt() is a one-way hash
-function).  As a result, this function isn't all that useful for
-cryptography.  (For that, see your nearby CPAN mirror.)
-
-When verifying an existing encrypted string you should use the
-encrypted text as the salt (like C).  This allows your code to work with the standard L
-and with more exotic implementations.  In other words, do not assume
-anything about the returned string itself, or how many bytes in
-the encrypted string matter.
+extirpated as a potential munition).
+
+cryp

Re: perlfunc sez crypt() encrypts... but it doesn't.

[Michael G Schwern]

On Sat, Jul 23, 2005 at 07:34:02PM -0400, John Peacock wrote:
> Michael G Schwern wrote:
> >crypt() doesn't really encrypt, it hashes or digests.
> 
> "encrypt" is a generic term.  "hash" or "digest" are specific methods.  
...
> So I think that trying to discuss the actual method used in the Perl 
> documentation is really going beyond what we need to do.  We could mention 
> that DES isn't all that secure, but trying to differentiate between 
> different encryption methods is outside of our scope (IMNSHO)... 

crypt() doesn't do generic encryption, its specificly a digest/hash function.
While its not so important that the user knows what hashing algorithm is used
it is important to make it clear that it is a non-reversable digest and not 
two-way encryption.

Most folks, when they hear "encryption" think lossless, reversable encryption.
Not a digest.


> More importantly for the purposes of documentation, at least on my system, 
> I see this:

Just because someone else does something poorly doesn't mean we have to, too.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Insulting our readers is part of our business model.
http://somethingpositive.net/sp07122005.shtml

Re: perlfunc sez crypt() encrypts... but it doesn't.

[John Peacock]

Michael G Schwern wrote:

crypt() doesn't really encrypt, it hashes or digests.


"encrypt" is a generic term.  "hash" or "digest" are specific methods.  More 
importantly for the purposes of documentation, at least on my system, I see this:


$ man crypt

NAME
   crypt - password and data encryption

SYNOPSIS
   #define _XOPEN_SOURCE
   #include 

   char *crypt(const char *key, const char *salt);

DESCRIPTION
   crypt  is  the  password  encryption function.  It is based on the Data
   Encryption Standard algorithm with  variations  intended  (among  other
   things)  to discourage use of hardware implementations of a key search.
...

So I think that trying to discuss the actual method used in the Perl 
documentation is really going beyond what we need to do.  We could mention that 
DES isn't all that secure, but trying to differentiate between different 
encryption methods is outside of our scope (IMNSHO)...


John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Re: perlfunc sez crypt() encrypts... but it doesn't.

[Russ Allbery]

Dave Mitchell <[EMAIL PROTECTED]> writes:

> Well pedantically speaking, crypt() encrypts a block of zeros using a
> DES variation and the supplied password as a key, so yes it does
> encrypt; but yes, it's use is as as a secure hash, so maybe the
> description could do with some polishing.

Not to mention that it's not a very *good* secure hash, given the
increasing ease with which one can brute-force DES.  It might be worth
pointing people at SHA1 or at least MD5 if they really care about
security.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: perlfunc sez crypt() encrypts... but it doesn't.

[Dave Mitchell]

On Sat, Jul 23, 2005 at 01:08:49PM -0700, Michael G Schwern wrote:
> crypt() doesn't really encrypt, it hashes or digests.  Yet perlfunc/crypt
> talks about encryption.  This seems misleading.  I discovered this while
> explaining that passwords aren't stored encrypted, they are hashed.  This
> not-encryption is done with the crypt() function--erk.
> 
> So I think it makes sense for the crypt docs to stop saying it encrypts.
> 
> I'm no expert in cryptographic terminology, can anyone confirm or verify this?

Well pedantically speaking, crypt() encrypts a block of zeros using a DES
variation and the supplied password as a key, so yes it does encrypt; but
yes, it's use is as as a secure hash, so maybe the description could do
with some polishing.

-- 
You never really learn to swear until you learn to drive.

perlfunc sez crypt() encrypts... but it doesn't.

[Michael G Schwern]

crypt() doesn't really encrypt, it hashes or digests.  Yet perlfunc/crypt
talks about encryption.  This seems misleading.  I discovered this while
explaining that passwords aren't stored encrypted, they are hashed.  This
not-encryption is done with the crypt() function--erk.

So I think it makes sense for the crypt docs to stop saying it encrypts.

I'm no expert in cryptographic terminology, can anyone confirm or verify this?


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in <[EMAIL PROTECTED]>

Re: What's holding up mainperl from upgrading MakeMaker?

[John E. Malmberg]

Nicholas Clark wrote:


However, VMS is currently failing to build even miniperl, due to its C
compiler being more stringent about const consistency than anything else
on the planet.


Being that stringent is important to be able to optimize code for modern 
CPU chips.


If it is not easy to fix by adding a const qualifier to the called 
routine, then the error is indicating what could be a data corruption issue.


-John
[EMAIL PROTECTED]
Personal Opinion Only

Re: What's holding up mainperl from upgrading MakeMaker?

[Abe Timmerman]

Op een mooie zomerdag (Saturday 23 July 2005 17:27),schreef  Nicholas Clark:
> On Sat, Jul 23, 2005 at 05:23:33AM -0700, Michael G Schwern wrote:
> > I see maintperl is still using MakeMaker 6.17.  What's keeping it from
> > using 6.30?
>
> I think that the problem was that MakeMaker 6.30 can't build SDBM_File on
> VMS.
>
> However, VMS is currently failing to build even miniperl, due to its C
> compiler being more stringent about const consistency than anything else
> on the planet.

I didn't check maint; just blead. I have started a 58x smoke on the VAX/
OpenVMS V7.2 just now...

HTH +
Good luck,

Abe
-- 
I'm not denying that it isn't a forest, I'm just leery of what will
fall down if we shake the trees too hard.
   -- Jarkko Hietaniemi on p5p @ 2002-02-12

Re: What's holding up mainperl from upgrading MakeMaker?

[Nicholas Clark]

On Sat, Jul 23, 2005 at 05:23:33AM -0700, Michael G Schwern wrote:
> I see maintperl is still using MakeMaker 6.17.  What's keeping it from
> using 6.30?

I think that the problem was that MakeMaker 6.30 can't build SDBM_File on
VMS.

However, VMS is currently failing to build even miniperl, due to its C
compiler being more stringent about const consistency than anything else
on the planet.

Nicholas Clark

Re: Smoke [5.9.3] 25214 FAIL(F) netbsd 1.5 (i386/1 cpu)

[Abe Timmerman]

Op een mooie zomerdag (Saturday 23 July 2005 17:29),schreef  Abe Timmerman:
> Automated smoke report for 5.9.3 patch 25214
> wodan: Intel Pentium II (Deschutes) (686-class) (i386/1 cpu)
> onnetbsd - 1.5
> using /usr/pkg/gcc-2.95.3/bin/cc version 2.95.3 20010315 (release)
> (NetBSD nb1) smoketime 22 hours 1 minute (average 1 hour 22 minutes)
>
> Summary: FAIL(F)
...
> Failures: (common-args) -Dcc='/usr/pkg/gcc-2.95.3/bin/cc' -Ui_db
> [stdio/perlio]
> [stdio/perlio] -DDEBUGGING
> [stdio/perlio] -Duse64bitint
> [stdio/perlio] -DDEBUGGING -Duse64bitint
> [stdio/perlio] -Duseithreads
> [stdio/perlio] -DDEBUGGING -Duseithreads
> [stdio/perlio] -Duseithreads -Duse64bitint
> [stdio/perlio] -DDEBUGGING -Duseithreads -Duse64bitint
> [stdio/perlio] -DPERL_COPY_ON_WRITE
> [stdio/perlio] -DDEBUGGING -DPERL_COPY_ON_WRITE
> [stdio/perlio] -DPERL_COPY_ON_WRITE -Duse64bitint
> [stdio/perlio] -DDEBUGGING -DPERL_COPY_ON_WRITE -Duse64bitint
> [stdio/perlio] -DPERL_COPY_ON_WRITE -Duseithreads
> [stdio/perlio] -DDEBUGGING -DPERL_COPY_ON_WRITE -Duseithreads
> [stdio/perlio] -DPERL_COPY_ON_WRITE -Duseithreads -Duse64bitint
> [stdio/perlio] -DDEBUGGING -DPERL_COPY_ON_WRITE -Duseithreads -Duse64bitint
> ../lib/version.tFAILED 79 173

Extending failures with harness:
../lib/version.t ../t/io/dup.t ../t/io/open.t

# Failed test (../lib/version.t at line 239)
#  got: '1.00_415543946100'
# expected: '1.23_0100'

# Failed test (../lib/version.t at line 239)
#  got: '1.00_415543946100'
# expected: '1.23_0100'
# Looks like you failed 2 tests of 183.


HTH +
Good luck,

Abe
-- 
Well, dereferencing that (as CvGV() would do) leads nowhere.  Or, as
the Ten Commandments for C Programmers quoth, "Thou shalt not follow
the NULL pointer, for chaos and madness await thee at its end."
   -- Jarkko Hietaniemi on p5p @ 2002-05-14

Re: [perl #2741] [BUG] version checking doesn't work per apparent docs

[John Peacock]

Michael G Schwern via RT wrote:

v1.2.3 style version strings are being "phased out" and should be
replaced by the various options presented by version.pm.


Well, no, not exactly.  v1.2.3 versions are likely to be the preferred format 
for Perl6 (AIUI), but the leading 'v' won't be a v-string any longer but rather 
a fullblown version number.  It's true that the version.pm module will permit 
compatibility for older Perl's, but the following are completely equivalent 
(under v5.9.3+):


package oldstyle;
use version;
our $VERSION = version->new(v1.2.3);

package newtyle;
our $VERSION = v1.2.3;

OK, I'm fibbing a little in that the first package will have a version object 
and the second will not (although I have a patch to do so), but both of them 
will emerge from UNIVERSAL::VERSION completely identically, i.e. as 1.002003). 
See below for why that distinction is important.




All the above now works in 5.8.6 with the exception of the final
"Argument "^AP" isn't numeric" warning which is still there.  As version
strings are going bye-bye will that ever be fixed?


It shouldn't be fixed, because the naive tests Tom was making in the second half 
of the bug were based on a flawed understanding of how the UNIVERSAL::VERSION 
sub operated then or now.  When called as a class method like 
IO::File::->VERSION, UNIVERSAL::VERSION merely returns the contents of the 
package $VERSION scalar.  As such, any special handling due to v-string, etc, 
doesn't happen at all.  And so there is no way that a bare == comparison will 
"know" anything about how to handle version comparisons vs. v-strings.


The only way to see whether the v-string versions are handled properly in Perl 
5.8.1+ is to 'use package v1' (and hence why all of the first half of the bug 
report now work fine).  It is not currently possible to compare a version number 
to a bare v-string and unless I make $VERSION a magical scalar to automatically 
upgrade to version objects (a patch I currently have working, BTW), it won't 
ever be possible in the general case.


With the patch I have to automatically upgrade the package $VERSION scalar to a 
version object, the following becomes true:



$ LD_LIBRARY_PATH=$PWD ./perl -Ilib -MIO::File -we 'print ref 
$IO::File::VERSION'
version



$ LD_LIBRARY_PATH=$PWD ./perl -Ilib -MIO::File -we 'printf "%d\n", 
$IO::File::VERSION == v1.120'
1



$ LD_LIBRARY_PATH=$PWD ./perl -Ilib -MIO::File -we 'printf "%d\n", 
$IO::File::VERSION == v1.121'
0


but when called as a package method, UNIVERSAL::VERSION returns the *numified* 
representation of the underlying version object, not the version object itself, 
so this will still warn:



$ LD_LIBRARY_PATH=$PWD ./perl -Ilib -MIO::File -we 'printf "%d\n", 
IO::File::->VERSION == v1.120'
Argument "^Ax" isn't numeric in numeric eq (==) at -e line 1.
0


I have delayed closing this ticket mostly through inertia.  With this 
explanation appended, it can now be safely closed I think.


John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

What's holding up mainperl from upgrading MakeMaker?

[Michael G Schwern]

I see maintperl is still using MakeMaker 6.17.  What's keeping it from
using 6.30?


-- 
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

Smoke [5.9.3] 25216 FAIL(F) bsd/os 4.1 (i386/1 cpu)

[kane]

Automated smoke report for 5.9.3 patch 25216
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 54 minutes (average 1 hour 57 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

   25216 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)

[perl #36634] Taking last element of an empty slice by putting it in scalar context. 5.8.2

[Rick Delaney via RT]

This is a dup of bug #30688.  It was fixed by change #23145.
Resolved.

[perl #5087] used only once warning for lexicals?

[Michael G Schwern via RT]

> [EMAIL PROTECTED] - Fri Jan 05 01:38:47 2001]:
>
> Maybe there's a reason for it, but...
> 
> ~ 12:35:18$ perl -wce '$count = 1;'
> Name "main::count" used only once: possible typo at -e line 1.
> -e syntax OK
> 
> BUT...
> 
> ~ 12:35:52$ perl -wce 'my $count = 1;'
> -e syntax OK
> 
> Shouldn't that warning be raised, regardless of scope?

I agree.  In fact the argument for the warning is even stronger for a
lexical.  A global seen only once... well maybe some other package grabs
at it.  But a lexical declared but never used is useless.

About the only counter argument I can see is that issuing the warning
for lexicals will cause a lot of existing code to start yelping.  But
that's what warnings are for.  I for one would like to know about unused
lexicals.

[perl #5070] Inconsistent arithmetic with % and * operators

[Michael G Schwern via RT]

> [EMAIL PROTECTED] - Thu Jan 04 10:10:18 2001]:
> 
> # The following complete four-line perl script produces unexpected
> # results on my machine.  The multiplication in the second line of
> # code below produces a negative result where a positive number is
> # expected, presumably because an integer multiplication was used
> # internally where a floating point operation was needed.  If the
> # expression is broken up and evaluated piece by piece then the
> # correct result is produced (line 4). (The difference between the two
> # results is, naturally, 2**32.)  The same results were produced under
> # perl v5.6.0.
> 
> my ($p, $x, $y) = (65537, 64645, 34463);
> print (($x % $p) * ($y % $p), "\n"); # produces -2067106661
> (incorrect)
> my ($a, $b) = ($x % $p, $y % $p);
> print $a * $b, "\n"; # produces  2227860635
> (correct)

Confirmed broken in 5.6.2.

Confirmed fixed in 5.8.0.


0 windhund ~/tmp$ perl5.6.2 test
-2067106661
2227860635
0 windhund ~/tmp$ perl5.5.4 test
-2067106661
2227860635
0 windhund ~/tmp$ perl5.8.6 test
2227860635
2227860635
0 windhund ~/tmp$ perl5.8.0 test
2227860635
2227860635
0 windhund ~/tmp$ perl5.8.1 test
2227860635
2227860635

[perl #4990] CORE::GLOBAL support broken in 5.6.0

[Michael G Schwern via RT]

> [EMAIL PROTECTED] - Wed Dec 20 04:02:32 2000]:
>  
> Importing subroutines into the CORE::GLOBAL package does not work.
> The perlsub documentation makes reference to the File::DosGlob
> module.  I've tested that the "GLOBAL_glob" export option for this
> module does not work.

Although I don't have a 5.6.0 to check with, 5.6.2 seems to work as
advertised.

$ perl5.6.2 -dwe '   use File::DosGlob 'GLOBAL_glob';  print
glob "*"'
Default die handler restored.

Loading DB routines from perl5db.pl version 1.07
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(-e:1):  use File::DosGlob GLOBAL_glob;  print glob "*"
  DB<1> 

As does 5.5.4, 5.8.6 and bleadperl.

[perl #4687] UNIVERSAL::isa can report incorrect results

[Michael G Schwern via RT]

> [EMAIL PROTECTED] - Mon Nov 13 00:10:45 2000]:
>
> If one package (say, Bar) is declared to be a subclass of another
> package
> (say, Foo) by assigning to the first package's @ISA array,
> UNIVERSAL::isa
> denies that Bar is a subclass of Foo unless Foo's stash has been
> created.
> 
> This prints nothing:
> 
> perl -le '@Bar::ISA = "Foo"; print "Bar"->isa("Foo")'
> 
> This prints "1":
> 
> perl -le '@Bar::ISA = "Foo"; $Foo::var = 1; print "Bar"->isa("Foo")'

This bug is still present in 5.8.6 and bleadperl.

[perl #2898] some reports on byteloaded modules

[Michael G Schwern via RT]

> [EMAIL PROTECTED] - Thu Mar 30 10:31:39 2000]:
> 
> You can kind create byteloaded modules and use them like
> regular ones.
> 
> Can we compile it?
> 
> % perlcc -b -o /tmp/Carp.pm `perl -MCarp -le 'print
> $INC{"Carp.pm"}'`
> [random noises deleted]
> [Exit 0]
> 
> That would be a yes.  Can we uncompile it?
> 
> % perl -MO=Deparse /tmp/Carp.pm
> /tmp/Carp.pm syntax OK
> % perl -MO=Deparse,-p /tmp/Carp.pm
> /tmp/Carp.pm syntax OK

5.8.6 and blead both fail with:

0 windhund ~/tmp$ perl -MO=Deparse Carp.pm
Can't locate object method "sibling" via package "B::NULL" at
/sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/B/Deparse.pm line 1188.
CHECK failed--call queue aborted.


> Well, yes and no.  We can uncompile other things.  This one
> seems unwillling, however.
> 
> May we run it?
> 
> % perl /tmp/Carp.pm
> [Exit 0]
> 
> Yes, we can!  Can we do anything cool with it?
> 
> % perl -e 'require "/tmp/Carp.pm"; Carp::carp("wow")'
> wow at -e line 1
>   require /tmp/Carp.pm called at -e line 1
> Not a CODE reference at -e line 1.
> perl in free(): warning: chunk is already free.
> Segmentation fault
> Exit 139

This now works in 5.8.6 and blead.

0 windhund ~/tmp$ perl -I. -wle 'use Carp;  print $INC{"Carp.pm"}; 
carp("wow")'Carp.pm
wow at -e line 1

[perl #2900] B::CC cannot sort

[Michael G Schwern via RT]

> [EMAIL PROTECTED] - Thu Mar 30 11:30:55 2000]:
> 
> This simple program:
> 
> for $k (sort { length $ENV{$b} <=> length $ENV{$a} } keys %ENV) {
>   print "$k=$ENV{$k}\n";
> } 
> 
> Under B::Bytecode, produces correct results, then SEGVs

Now working in 5.8.6.

> Under B::C, produces correct results, then exits correctly.

Still working in 5.8.6.

> Under B::CC, produces no results, but goes into recursive 
> doom in the sort, eventually SEGVing for lack of memory
> in stack death.

$ perlcc -O foo
/sw/bin/perlcc: foo did not compile, which can't happen:
Can't locate object method "_save_common_middle" via package "B::FAKEOP"
at /sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/B/C.pm line 389.
 CHECK failed--call queue aborted.

Same for bleadperl.

[perl #2741] [BUG] version checking doesn't work per apparent docs

[Michael G Schwern via RT]

> [EMAIL PROTECTED] - Tue Mar 28 03:38:58 2000]:
> 
> From perldata:
> 
>A literal of the form `v1.20.300.4000' is parsed as a string
>composed of characters with the specified ordinals.    Such
>literals are accepted by both `require' and `use' for doing a
>version check.
> 
> This is not true, however.  Witness:
> 
> % perl -MIO::File -le 'print IO::File::->VERSION
> 1.08
> 
> % perl -e 'use IO::File  1.08'
> 
> % perl -e 'use IO::File  v1.08'
> Octal number in vector unsupported at -e line 1, at end of line
> BEGIN not safe after errors--compilation aborted at -e line 1.
> 
> # vector?  qu'est-ce que c'est qu'un vector? 
> # did I vec() something for select()?
> 
> % perl -e 'use IO::File  1.8'
> IO::File version 1.8 required--this is only version 1.08 at -e line 1.
> BEGIN failed--compilation aborted at -e line 1.
> 
> % perl -e 'use IO::File  v1.8'
> 
> % perl -e 'use IO::File  1.8.2'
> 
> % perl -e 'use IO::File  v1.8.2'
> 
> % perl -e 'use IO::File  1.9.2.20'
> 
> % perl -e 'use IO::File  v1.9.2.20'
> 
> % perl -e 'use IO::File  1.9.9'
> 
> % perl -e 'use IO::File  1.9..999'
> 
> % perl -e 'use IO::File  v1.9.9'
> 
> % perl -e 'use IO::File  v1.9..999'
> 
> ### Ick ick ick!  Something sure smells pretty icthy around here.
> 
> # And here's some naive stuff.  Remember: version were always numbers
> # before.  So one expects numbers to continue to work.  But they don't.
> # And produce very odd msgs.
> 
> % perl -MIO::File -e 'printf "%d\n", IO::File::->VERSION >  1.8'
> 0
> 
> % perl -MIO::File -e 'printf "%d\n", IO::File::->VERSION >  v1.8'
> 1
> 
> % perl -MIO::File -e 'printf "%d\n", IO::File::->VERSION <  1.8'
> 1
> 
> % perl -MIO::File -e 'printf "%d\n", IO::File::->VERSION <  v1.8'
> 0
> 
> % perl -MIO::File -e 'printf "%d\n", IO::File::->VERSION == 1.08'
> 1
> 
> % perl -MIO::File -e 'printf "%d\n", IO::File::->VERSION == v1.08'
> Octal number in vector unsupported at -e line 1, at end of line
> Execution of -e aborted due to compilation errors.
> 
> # octal huh?
> 
> % perl -MIO::File -e 'printf "%d\n", IO::File::->VERSION == v1.80'
> Octal number in vector unsupported at -e line 1, at end of line
> Execution of -e aborted due to compilation errors.
> 
> % perl -MIO::File -we 'printf "%d\n", IO::File::->VERSION == v1.80'
> Argument "^AP" isn't numeric in numeric eq (==) at -e line 1.
> 0
> 
> # That's disgusting.  Run it through uncontrol!

v1.2.3 style version strings are being "phased out" and should be
replaced by the various options presented by version.pm.

All the above now works in 5.8.6 with the exception of the final
"Argument "^AP" isn't numeric" warning which is still there.  As version
strings are going bye-bye will that ever be fixed?

[perl #2744] [BUG] perlcc bugs (about seven or eight of them)

[Michael G Schwern via RT]

> [EMAIL PROTECTED] - Tue Mar 28 03:39:04 2000]:
> 
> % cat bad
> #!/usr/bin/perl
> 
> sub fn {
> local $key = "I am the key!";
> print "Have: $key\n";
> }
> 
> fn();
> % perl bad
> Have: I am the key!
> 
> % perlcc bad
> 
>

> Compiling bad:
>

> 
> ERROR: 'bad' does not have a proper extension!

This silly behavior appears to have been fixed.  5.6.2 and 5.8.6 both
take "perlcc bad" fine.

I can also compile the program.  5.6.2 and 5.8.0 compile with no
problem.  5.8.6 warns:

0 windhund ~/tmp$ perlcc bad
pccM2diy.c: In function `perl_init_':
pccM2diy.c:1205: warning: this decimal constant is unsigned only in ISO C90

bleadperl is downright boisterous.  Its output is attached.  I'm leaving
this ticket open because of all the warnings.


perlcc.out
Description: Binary data