Perl 5 Porters Mailing List Summary: November 2nd-9th

Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past week, including Monday the 9th. Enjoy!

November 2nd-9th


Ricardo Signes is updating that the #onionsketch is back! Wednesday, November 18th is the next sketch meeting, at 14:00 NYC time.

Craig A. Berry shared his latest patch on Perl #126403, that addresses speeding up read on Windows, which seems very promising.

A grant report by Tony Cook, the summary of which is:

Approximately 16 tickets were reviewed or worked on, and 6 patches were applied.

Tony's September grant report is also available. Tony worked or or reviewed approximately 42 tickets.

H.Merijn (Tux) Brand updates that Getopt::Long is now available on Github.

Tony Cook opened a meta ticket, Perl #126546, to keep track of any issues detected by fuzzing.

Jarkko Hietaniemi provides an update on his Coverity work.

Tony Cook is trying to resolve (unrelated tickets) Perl #126042 (fuzzer-found segfault) and Perl #57512 (implicit close silently unchecked for error), providing patches for both.

Bulk88 is continuing his quest to remove bootstrap files and proposed two patches to handle this.

Bulk88 also provided two patches (that were already applied by Tony Cook) to re-parallelize Win32 builds (after Unicode::Normalize was reimplemented in XS, and to remove useless build product file /win32/config.w32.

A problem raised and solved in Perl #126582 by Jarkko Hietaniemi on accidental bit-shifting, following a discussion (mentioned under Discussion below).

Bulk88 updates everyone that perl was forked by Michael Schwern under the name piledriver.


Reported bugs

Perl #126162, reported by Andreas J. Koening (in turn from a report by Slaven Rezić). A commit in perl which changes how stat behaves when receiving an array breaks perl5i.

Perl #126544, reported by Jim Avera, asks to document variables used in the synopsis of the fcntl function.

Perl #126556, reported by Atoomic, raises the question on destruction when using an INIT block. More on that under Discussion below.

Perl #126552, reported by Shlomi Fish, raises a possible bug in the Perl Debugger, which turns out to be a case of confusing closures.

Perl #126579, reported by Ricardo Signes, notes that after resolving Perl #121085 (warning on filenames with newlines), there is still a warning even after a newline is stripped by a two-arg open call.

Perl #126586, reported by Jarkko Hietaniemi, relates to Perl #126582 and the parsing of hexadecimal floats.

Perl #126593, reported by Andreas J. Koening (discovered by Slaven Rezić), Bleadperl breaks App::test::travis.

Resolved bugs


Michael Felt (from AIXTools) sent an email to p5p asking for help digging into a segmentation fault he's exploring.

Yaroslav Kuzmin emailed about a hanging test in z/OS. Karl Williamson is already on it, providing branches to test out a fix.

Zsbán Ambrus asks about comparisons of integers and floating point numbers. Zefram responded that a comparison of mixed types was never planned to behave well and would be more complex and expensive. Ambrus disagrees but notes that difficult to implement correct and to test properly.

In Perl #126556 question on expected behavior (and the documentation of such) with regard to destruction when using an INIT block. It does not seem to be a bug but could possibly a problematic limitation. Todd Rinaldo tries to carefully describe it as:

So to rephrase what we're saying here: We're saying that any variable used in an INIT block like this either needs to be weakened or will never be destroyed until global destruction? I'm inclined to say that's a problem. At the least it should be documented right?

Philip Prindeville asks about a possible feature for IO::Pipe allowing you to have access to the child PID. Chas Owens suggested using open instead.

Bulk88 suggests that distributions (such as Carp) which keep their development history in the perl core repository be separated into their own repository with their own history.

In the discussion around unsafe signal handlers in Perl #126474 Leon Timmermans suggests checking out his Signal::Pipe module and Tony Cook has additional comments on possible improvements in the noted case.

Continued discussion in Perl #126437 about the documentation of hex and now its behavior as well.

Ricardo Signes adds in Perl #121766 he's not sure how to address the regression problem without reintroducing old problems.

A discussion started on support of hexadecimal floats yielded the following interesting observation, described by Jarkko:

So it really does look like the hexfp parsing code implementation is leaking over to supporting unintentionally also binary and octal...

Additionally, I will begin quoting the following emergent description of Perl, a result of a conversation on the ticket between Eirik Berg Hanssen and Jarkko:


... that's just emergent behaviour? Cool! :)


"Emergent behaviour" describes the whole of Perl rather beautifully, don't you think?

1 Comment

Sawyer X, thank you so much for doing this!

Leave a comment

About Sawyer X

user-pic Gots to do the bloggingz