This Week on p5p 2000/03/05
- Brief Update
- Module Warnings
- POD Changes
- Race conditions in statndard Perl utilities
openCalls not checked in
- Big Flame Wars
- Chip and Jarkko Quit
- Templates in
use strictin the core modules
Well, my apologies to everyone for the long absence. I’m going to try to send out reports more frequently, and to let go some of my obsession about being completely complete, and see if I can stay on schedule.
This means that if you think I missed something of importance, I would be more grateful than ever if you would bring it to my attention.
You can subscribe to an email version of this summary by sending an empty message to
Please send corrections and additions to
YYYYMM is the current year and month.
Since last time, Perl has had three beta releases and now stands at version 5.5.670.
In the wake of this, list traffic is very high with various small bug reports and configuration problems.
Paul Marquess added functionality to the
warnings.pm lexical warnings module so that a module could peek at the warnings that are enabled in its caller, and issue similar sorts of warnings. For example, your function might issue a warning about a newline at the end of its filename argument, but only if your function’s caller has the
newline category of warnings enabled.
Paul asked whether it would be a good idea to allow modules to be able to register their own warning categories, and presented a possible interface to such functionality. Then you might say something like
use Fred; use warnings 'Fred';
to turn on the warnings that were special to the
Fred module. Paul asked for comments from the list about this. Original message
There was a lot of interesting discussion of this. Paul said that he had thought about making it possible for a module to define its own hierarchy of warnings, but that that seemed like overkill. Ron Kimball suggested that
use warnings 'Fred' or
no warnings 'Fred' might enable or disable warnings from module
Fred regardless of whether or not
Fred had registed its own warning category. Paul said he had considered this, but that it would suggest to people that doing
use warnings 'Some::Module' would necessarily do something useful, when in fact
Some::Module might not issue any warnings at all.
Yitzchak Scott-Thoennes pointed out that if module names are warning categories, then you could put explanations of your warnings into your module’s POD and then
diagnostics would be able to find the explanations or your own module’s warnings.
5.5.670 brought with it some changes to the structure of POD. In particular, the old problem of putting angle brackets into
C<...> tags is probably solved. You can now write C<<$var->method >> and the rule is that the text to be output is delimited by the double-angle brackets and whitespace.
Changes went into
Pod::HTML to support this. Robin Barker pointed out that
pod2latex still did not support this and other changes, and rather than dig into the horrible squiggly guts of
pod2latex to fix it, he wrote a preprocessor (using
Pod::Parser which removes the new escape codes from a pod document and yields an old-style POD. He bolted this to the front of
pod2latex, which in my opinion was the right thing to do. Way to cut that gordian knot, dude.
Race conditions in statndard Perl utilities
Tom Christiansen posted a `Request for Hero’ to fix the parts of the Perl distribution that write files to
/tmp in an unsafe way, laying themselves open to race condition exploits and soforth. A typical problem is that
/tmp is world-writable, so a malicious person could remove the temporary file and replace it with a new one before the program notices. Worse, if the superuser is running the program, a malicious user might remove the temporary file and replace it with a symbolic link to the password file; when the program updates what it thinks is the temporary file, it is really updating the password file.
Tom listed several utilities that may have these problems, including
s2p although he also said that none of these bugs were actually in the core. Read about it.
Tom called for a core
File::Temp module that would encapsulate safe temporary file creation functions.
Tim Jenness said that he had written such a thing about a year ago, and he volunteered to be the hero. Discussion of various attacks via
open Calls not checked in
Tom posted a related note, showing about half a dozen places in
perldoc where a system call, usually
open, was performed with no check of the return code.
Big Flame Wars
Somehow the `
open calls’ discussion turned into a gigantic flame war.
If it’s not too late, I advise skipping it. The subject is `security (and stupidity) bugs in perldoc’.
Chip and Jarkko Quit
Chip Salzenberg and Jarkko Hietaniemi quit p5p, citing big flame wars as the reasons. Chip created a new mailing list, which is supposed to be just like p5p, except that ``verbal abuse will not be tolerated.”
Leaving aside any questions of how Chip plans to enforce this, I believe that forking p5p is an incredibly bad idea. I can only hope that the new list will turn out to be irrelevant, but I’m really afraid that it will draw off just enough of the productive people from the main list to prevent both groups from being effective.
I’d love to revisit this in a year and find out that I’m wrong.
Way back in October, Ilya had an idea for making
unpack capable of automatically unpacking data in any format, even one that was not known in advance. I wrote this up in October, but Ilya’s new messages now suggest that I didn’t understand the point. Ilya says:
Ilya: There were some initial objections due tomisunderstanding of the posted example: people thought that theexamples of serialization I initially posted for illustrationwere the only ways to serialize data.
is probably worth reading, but skip the rest of the thread. It was a waste of time even before the tail end of this thread was sucked into the flame zone.
use strict in the core modules
Peter Scott asked why 84⁄109 core modules did not use
strict. That is a good question, and I don’t think the answer is going to turn out to be `carelessness and hystorical accident’. At least, not in every case.
If someone did go around putting
use strict into all the core modules, I think it would be a real good idea if they also kept track of how many actual bugs they found andcorrected as a result, and how many non-bugs.
A large collection of bug reports, bug fixes, non-bug reports, questions, and answers. Also spam.
Until next time I remain, your humble and obedient servant,
Something wrong with this article? Help us out by opening an issue or pull request on GitHub