This Week on p5p 1999/12/26


Last year I fell behind on reports because I took three business trips in two weeks. I still haven’t caught up, so I am going to skip the last couple of reports. I was going to skip this week’s report also, but it was so small I decided to do it anyway. The next report should be for 9–15 January. Sorry for the inconvenience.


You can subscribe to an email version of this summary by sending an empty message to

Please send corrections and additions to where YYYYMM is the current year and month.

Module Interface and Version Meta-Information

Last week a discussion started about how to put version information into modules in a standard way, and Sam Tregar suggested that there be a convention that the version information and other module interface information be stored in the POD documents. Discussion on this continued. I should probably have mentioned it in the pervious report.

Sam’s message

SVs by Default

When you create a GV (glob value) in Perl, it has its SV slot filled automatically. For example, when you define @foo or sub bar you get space allocated for $foo and $bar automatically. The rationale behind this is presumably that scalar variables are very common and you might as well preallocate them. (I suppose this is why defined *{foo}{SCALAR} always yields true.)

Nick Ing-Simmons complained about this, saying that many SVs are allocated that are never used, and that the original assumption, that SVs are very common, may not be true now that most scalar variables are lexical.

I did not see a resolution of this.

Another return of PREPARE

In an earlier report,I mentioned that Ilya’s PREPARE feature had not gone innto 5.005_63. Sarathy added that it would not go into 5.005_64 either unless it was fixed to not use a new opcode.

I mention this because Ilya replied that Perl needs twenty or thirty new opcodes, and that last year he demonstrated that by introducing new opcodes that atomically combine two or more other opcodes that often appear in sequence, some operations might be sped up by a factor of two. This was interesting, although it is not clear that it has anything to do with PREPARE.

Original discussion

Later followup

More Flushing Problems

Someone with no name submitted a bug report that pointed out that if you call truncate Perl truncates the file without flushing the stdio buffer. This is only the most recent in a very long series of similar, related bugs. I wonder why this is so hard to get right? Is it just that nobody has taken it up?

Ilya said that the last time this had come up, he suggested that Perl should always flush the buffer between any buffered and unbiffered operation, and between any read and any write, but ``The result is nil.”


Last week’s discussion Andrew Ford reports that this is finished, and is available at It will appear on CPAN eventually.

#line directives

Andrew Pimlott pointed out that a #line directive in a require’d file inherits its implicit filename not from the file it is in, but from the file that required it. Apparently this is a feature. Andrew submitted a patch changing the behavior. There was no followup discussion. I do not know if the patch was accepted.


HÃ¥kon Alstadheim supplied a patch to Devel::DProf that allows the user to specify the data output file, via an environment variable.


A medium-sized collection of bug reports, bug fixes, non-bug reports, questions, and answers. Apparently the spammers were all on vacation.

Until next time I remain, your humble and obedient servant,

Mark-Jason Dominus



Something wrong with this article? Help us out by opening an issue or pull request on GitHub