This Week on perl5-porters (25 November / 1st December 2002)
This week, the bulk of the discussion comes from bug reports. Using my
discriminative summarizer powers, I've selected some to be featured in
this new instance of the P5P summary.
Reference to an undefined value
Nicholas Clark remarks that the "strict 'refs'" pragma doesn't produce
consistent errors when an undefined value is dereferenced (bug #18635).
For example, "push @$a, "foo";" is allowed when $a is undefined, while
"print @$a;" dies with an error ("Can't use an undefined value as an
ARRAY reference"). At first sight, the difference between the two
constructs is that in the first form $a is modified (by
autovivification), while it's only read in the second. However this
doesn't actually explain, semantically that is, why "print for @$a" or
"defined @$a" are still allowed under "strict 'refs'".
As a conclusion to the thread, Rafael Garcia-Suarez suggests to build a
matrix with all possible cases and work out what the proper behaviour
must be.
http:[EMAIL PROTECTED]/msg89322.html
Fun with syntax
Nicholas Clark (again) found an interesting way to confuse the
tokenizer. The following snippet :
print "$a{'"
#'}";
is understood by perl as "print qq[$a{'#'}";\n];" (according to
B::Deparse.) Apparently nobody understands what happens there.
http:[EMAIL PROTECTED]/msg89374.html
MakeMaker PREFIX regression
Michael Schwern received bug reports for ExtUtils::MakeMaker, telling
that the recent versions (such as the one distributed with perl 5.8.0)
break the following installation prefix specification style :
perl Makefile.PL PREFIX=foo
make test
make install PREFIX=bar
This is due to the massive refactoring Michael did on MakeMaker, where
he didn't realized that this case was actually useful to some. He asked
for advice on how to tweak the generated Makefile (portably) to include
a default value for macros.
http:[EMAIL PROTECTED]/msg89366.html
Restricted hashes bug
A strange bug (#18651) has been found, related to restricted hashes (and
the Hash::Util module). When the hash has been made read-only with the
lock_keys() function, and when the keys are deleted from the hash then
reintroduced again, under some conditions a key may disappear from the
return value of the built-in keys(). Apparently this bug depends also on
the key names. Nicholas Clark provided a first draft patch. He also
commented that he considers this bug serious enough to recommend not
using restricted hashes with perl 5.8.0.
http:[EMAIL PROTECTED]/msg89318.html
In brief
H.Merijn Brand reported that the test t/io/openpid.t doesn't hang
anymore on AIX 4.3.3, after a compiler upgrade (to vac 5.0.2.6). Smokes
for this system are restarted.
The DESTROY() methods, that used to be called in scalar context, are now
called in void context. Let's see if this breaks something.
Jarkko Hietaniemi asked that the bugs that have been fixed should be
marked as such in the perlbug database, as it's not cleaned up at night
by a magical army of little gnomes. Robert Spier also plans to send a
weekly summary of new and open bugs.
Eduardo Pérez Ureta provided a first patch to implement the improvement
he suggested last week to the "-i" command-line switch, but he got no
feedback yet.
Chip Turner (maintainer of Perl for RedHat) asked again about bug #18265
(concerning nonblocking I/O), reported at the beggining of november.
Brendan O'Dea (maintainer of Perl for Debian) adds that this problem
(also reported on Debian) seems to be dependent on the build
environment.
Yves Orton stirred up the list about the assertion-in-perl patch,
submitted two weeks ago by Salvador Fandiño. He likes this feature
proposal and doesn't want it to be overlooked. Hugo commented that he's
still on catch-up mode on the patches, but plans to look at it in
detail. Salvador then proposed a new version of his patch.
Jarkko tried to fix bug #16823 (multibyte characters can't be used as
separators for the various quotelike operators), but it turned out that
the bug is a lot more complicated than it appears in a preliminary
inspection, due to the various possible encodings that may be used by
the source file.
Bug #18717 is about some regression tests failing ungracefully when the
TERM environment variable contains a dot. In this case, the taint checks
report the error message "Insecure $ENV{TERM} while running with -T
switch". Slaven Rezic comments that he doesn't understand why TERM is
considered dangerous when it contains metacharacters. A quick fix would
be to set "TERM=dumb" before running the failing tests.
Marc Lehmann reported bug #18779, about a lexical variable being
mysteriously reset when declared in the conditional of a "while" loop
that uses "redo".
James Mastros remarks that the "${^TAINT}" special variable is set to 1
both under real taint mode ("-T") and under taint warnings mode ("-t").
He asks for a way to distinguish between those modes.
About this summary
This summary brought to you by Rafael Garcia-Suarez, both on
http://use.perl.org/ and via a mailing list, which subscription address
is [EMAIL PROTECTED] Comments and corrections are, as
always, welcome.
