In newer versions, however, it works very nicely - never had any problems with it in a complex multi-threaded application.

BTW, I think that the adjective "broken" is used in our world not necessarily for "has a bug". Sometimes it's referred to "not behaving as one would expect".

The experimental regex features introduced in 5.6 are still experimental. Most seem to work fine, but interactions between Perl code in code subexpressions and Perl code outside the regexp seem to bite people from time to time.

AFAIK at least some of the regex expressions you mean will always be marked "experimental" in some way or another. The reason is that the interactions of the "normal" regex engine, the optimiser and run-time optimisation vary with different versions of perl and as these regops allow one to "see through" to the behaviour of the engine itself their behaviour becomes not well defined. The experimental marking is there so that people know the results of using them will vary with perl to perl.

A good example would be the following two snippets which should be functionally equivelent but don't do the same thing because the code block violates the encapsulation of the regex engines behaviour.

E:\>perl -le "print 'foo baz'=~/(foo|foo|foo)\s(?{print qq(Got '$1')})
+ba[r]/ ? qq(Matches '$1') : 'No match!'"
Got 'foo'
Got 'foo'
Got 'foo'
No match!

E:\>perl -le "print 'foo baz'=~/(foo|foo|foo)\s(?{print qq(Got '$1')})
+bar/ ? qq(Matches '$1') : 'No match!'"
No match!
[download]

The reason this happens is that the tail part of the regex (the 'bar' part) allows the regex engine to use Boyer-Moore matching as an optimisation to find each 'bar' in the string being searched and then start the match process from relative to these matches, which means that in the fail case the "real" regex engine never actually kicks in. By putting a character in the fixed string into a class the Boyer-Moore matching is bypassed and the slower process of trying the pattern at each offset in the string occurs which results in the (?{}) block executing.

As more and different optimisations get added to the regex engine you can expect further changes of this sort. Actually as a matter of fact Perl 5.9.2 will produce a different result for the ba[r] example in that it will only print "Got 'foo'" once and not three times.

---
demerphq

In my humble opinion the attributes (per attributes.pm) is broken. The first and perhaps most obvious and omnipresent problem is that there's no clean way to flag a variable or subroutine with an attribute. If I do my $foo :Foo;, how do I later see if $foo has the attribute Foo?

The second problem is subroutine attributes. In the attribute handler (MODIFY_CODE_ATTRIBUTES) the subroutine is not yet fully defined. There's even no way to distinguish between anonymous subroutines and named subroutines. It doesn't even have an internal name yet, no flags set, no stash. Nor does it have any eventual prototype set. Pretty much nothing. The attribute handler is called too early. This is by current design, but a broken design imho. This is the reason Attribute::Handlers resorts to a (broken) INIT workaround. While Attribute::Handlers was a good initiative and helped to show the niceness of attributes it doesn't solve the next major issue: namespaces for attributes. Attribute::Handlers rather works against a solution in that it encourages one to create global attributes. When I search CPAN a while back I found 28 modules that defined attributes. Out of these 26 polluted the UNIVERSAL namespace.

I see a lot of potential in attributes. As their current implementation is so poor I personally frown upon their usage. Therefore I've been working on a set of modules that aim to make attributes usable and a working tool to write even nicer Perl code. In large, my modules aim to

• provide namespace scoping and import/export,
• allow reflective programming for subroutines, and
• free the programmer from the need to use a module to define attributes.

If anyone is interested please contact me and I'll try to free off time during the next weeks to write an RFC to post here on Perl Monks. I'm of course happy to receive any ideas by mail too.

Regards,
J Lodin (LODIN at CPAN)

Edit: added a space after the cpan link... arrgh.

Can you characterize your bug a little more specifically? File::Find works perfectly for me with respect to symlinks, whether they point somewhere or not. In fact, I often use File::Find to locate dangling symlinks:

use File::Finder; # my wrapper around File::Find
@nowhere = File::Finder->eval(sub { -l and not -e })->in($ENV{HOME});
[download]

So, what is your brokenness?

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Apologies for the delay, had to fetch File::Finder as it's not in the core perl and I wanted to have both methods detailed in the script.

Here's a testcase:

#!/usr/bin/perl
# pragmata
use warnings;
use strict;
use integer;
# Modules
use File::Finder; # merlyns wrapper around File::Find
use File::Find; # core module
# Prototypes
sub wanted;
sub dangling_symlink_handler;
sub goFinder($);
sub goFind($);
#
my $pathname = shift; chomp ($pathname);
print "Querying Perhaps Broken Symlink Handling For $pathname \n";
#
# generic find should grab anything and get anything that is valid
print "call goFinder:\n";
goFinder($pathname);
print "done goFinder:\n";
print "call goFind:\n";
goFind($pathname);
print "done goFind:\n";
###################################################################
sub goFinder($){
        my $searchpath = shift (@_);
        my @goodlinks = ();
        my @badlinks = ();
        print "in goFinder($searchpath)\n";
        # Slightly modified merlynish example
        @goodlinks = File::Finder->eval(sub { -l and -e })->in($search
+path);
        foreach (@goodlinks) {
                print "File::Finder Found good link:$_"."\n";
        }
        @badlinks = File::Finder->eval(sub { -l and not -e })->in($sea
+rchpath);
        foreach (@badlinks) {
                print "File::Finder Found bad link:$_"."\n";
        }
        print "exiting goFinder($searchpath)\n";
}
sub goFind($) {
        my $searchpath = shift (@_);
        print "in getFileList($searchpath)\n";
        find( { wanted => \&wanted, no_chdir => 1, dangling_symlinks =
+> \&dangling_symlink_handler }, $searchpath);
        print "exiting getFileList($searchpath)\n";
}
sub wanted {
        print "\tWanted Sees This:\n\t".$File::Find::name."\n";
}
sub dangling_symlink_handler {
        print "\tDangling Symlink Handler Sees This:\n\t".$File::Find:
+:name."\n";
}
[download]

So there it is, the stock File::Find find function doesn't call the dangling_symlink_handler as advertised (or as I read it's advertisment) and your File::Finder module finds stuff just fine, either it works around this behavior properly or I'm misunderstanding its behavior. As File::Finder is not a core module, I hadn't used it up 'til now thus avoiding convincing my superiors to allowing its installation.

Squibbie Pooh Ski Doo.

I'll put together a demonstration case of the failure, but with both the AIX and Gentoo Linux version of perl the dangling symlink handler never gets called for me.

This is with perl versions 5.8.5 on Linux and 5.8.0 on AIX 5.

Squibbie Pooh Ski Doo.

It isn't going to work as we would like because the structural changes required are basically a complete rewrite.

"not working" is best defined as

This is a bug that we're working on that will be fixed soon.

INIT is "broken" and won't be fixed until Perl6. Unicode and threads, however, were "not working" in Perls before 5.8. (Unicode is arguably still "not working", but that's now a PBKAC, not with Perl.)

What about "this is a bug but no one cares to fix it"?

Update: added the small text.

ihb

See perltoc if you don't know which perldoc to read!

If no-one cares, then is it a bug?

---

The Perfect is the Enemy of the Good.

It made me wonder what else is considered (more or less officially) broken in Perl 5

I'd put Perl 5's prototypes into the broken category.

The name is broken because almost everybody thinks of things like C's prototypes where Perl's prototypes are a completely different beast.

Secondly they're not general enough - witness the fact that there are several built in functions that cannot have their calling-style represented with a prototype.

Perl 6 will, of course, fix this with its much more flexible calling syntax and grammar system.