http://qs321.pair.com?node_id=988835

worenklein has asked for the wisdom of the Perl Monks concerning the following question:

This is perl, v5.10.0 built for sun4-solaris (By the way, the minimal snippet does not have -w and strict, but who writes code without those?)
#!perl510 -w use strict; sub foo(); foo(); sub foo() { my $foo; format STDOUT = ^ $foo; . $foo="X"; write; }

Replies are listed 'Best First'.
Re: This code snippet causes Perl to SEGV
by davido (Cardinal) on Aug 21, 2012 at 21:24 UTC

    The following is not going to answer the question of why the code you provided causes a SEGV. It's more a commentary on where to place expectations and which foot-paths are most likely to lead to a destination rather than petering out in dense brush. It's bound to be full of generalizations, and p5p experts may find inaccuracies. (Corrections are welcome.)

    Since there are almost never serious backward incompatibilities introduced between minor version numbers with Perl, and since minor releases almost always provide bug-fixes and security-fixes (rather than new features), it's usually advisable to upgrade to the most recent minor release within whatever major release you're stuck with.

    These are the most recent minor releases for each major release (as of 8/21/12):

    • Perl 5.16 branch: perl-5.16.1
    • Perl 5.14 branch: perl-5.14.2
    • Perl 5.12 branch: perl-5.12.4
    • Perl 5.10 branch: perl-5.10.1
    • Perl 5.8 branch: perl-5.8.9
    • Perl 5.6 branch: perl-5.6.2
    • Perl 5.5 branch: perl5.005_04
    • Perl 5.4 branch: perl5.004_05
    • Perl 5.3 branch: perl5.003_07
    • (Source: perlbrew available)

    In fact, it's rather pointless to discuss bugs in, for example, 5.10.0, since 5.10.1 is the bug-fixes that found their way into the 5.10 branch. 5.10.0 isn't the current version within the 5.10 branch. The red phone has been disconnected from 5.10.0. If any hotline still exists for the 5.10.x branch, it will direct calls to 5.10.1's red phone. If the bug can be reproduced in 5.10.1 (and maybe it can), that's a slightly different situation, as it affects the current 5.10.x release.

    Furthermore, Perl-5's current development strategy is to support the two most recent even-numbered major releases. Currently that covers 5.16.x and 5.14.x. So 5.12.x and earlier are no longer actively supported. It's possible that a giant security problem being discovered in 5.12.4 would prompt a new release of 5.12.x, but P5P isn't going to feel a whole lot of urgency, and the further back you go the less likely it will be that such a discovery would result in a new release within the major version.

    Formats are another can of worms in addition to the maze of Perl versions and active support. It's hard to imagine a templating system in Perl that could have more caveats, quirks, and warnings (while at the same time receiving less attention) than formats. Lightweight tasks are often pushed back to printf, and others are upgraded to real templating systems like Template::Toolkit, HTML::Template, Text::Template, and even framework-specific template systems like Mojolicious's Embedded Perl templates (each undoubtedly with its own quirks ;). Native formats just aren't used all that often, which is why they probably haven't seen much refinement over the years.


    Dave

Re: This code snippet causes Perl to SEGV
by FunkyMonk (Chancellor) on Aug 21, 2012 at 22:13 UTC
Re: This code snippet causes Perl to SEGV
by Marshall (Canon) on Aug 21, 2012 at 20:29 UTC
    I ran this code on my Windows machine and also got a seg fault. When I first saw this "format" thing in Perl, I thought that it would be way cool. That initial idea turned out to be very, very wrong - there are limitations and weirdness with this idea. Something is wrong with the "format" statement, and I don't know exactly what.

    My advice and what I do is to steer clear of this "format" statement and instead use standard printf style formatting specs. printf ("some data: %4d\n", $foo); or whatever. There are modules to help with complex textual tables, but in my experience they are seldom needed.

    Summary: Use the extremely well debugged standard 'C' style family of formatting specs.

    Update:
    One of the issues here is that this "format" gizmo speaks to a different era in programming (punched cards and fixed field widths with no "column" separator characters). With the printf() format specs you can specify a minimum width for the field. If the data takes more characters than the print spec says, then it will put more characters in. This is almost always what is wanted. Use an explicit space character between fields like (%4d %4d) so that if the first int overflows, there will be a space between that and the next field, this better than say (%5d%5d) because that does not guarantee a space between fields. Perl is designed to parse space separated tokens very, very well.

    use format if you will, the last time I used it was in Perl 5.6. Perl 5.10 may have a bug. I'm just saying that since Perl 5.6, I have found other ways to do what I want.

Re: This code snippet causes Perl to SEGV
by Anonymous Monk on Aug 21, 2012 at 20:08 UTC

    This is perl, v5.10.0 built for sun4-solaris

    There is your problem, 5.10 had serious bugs

    (By the way, the minimal snippet does not have -w and strict, but who writes code without those?)

    warnings is better than -w

      warnings is better than -w

      s/better than/different from/.

      warnings.pm was created (based on the justifications I've seen repeatedly expressed) to address a specific problem that was sometimes annoying with -w. It also (at least now) includes several less-often-used features that are rather tangential to a comparison against -w.

      But (not too surprisingly, at least to me) it also introduced new annoyances, some of which are improved by using good, old -w.

      I have a version of a module that does 'use warnings;' and the biggest problem with that version is that it produces a warning for no good reason and there is no good way to prevent that. This is almost identical to the annoyance that appears to have motivated the creation of warnings.pm and is often used as justification for calls to replace '-w' with 'use warnings;' (just in reverse).

      I use -w a lot more often than I write use warnings;.

      In unit tests for a module, I use -w because I want to see warnings not just in the unit test code and not just in the module being tested, but also warnings caused in other modules by values (usually undef) leaked from my module.

      Similarly, in scripts where I'll see the warnings, I use -w for similar reasons.

      In my modules, I usually do neither because I think it should be up to the user of the module as to whether or not they want to see warnings from my module, especially since such would likely be caused by values leaked in from outside of my module (or by cases that I didn't run into when testing -- note that CPAN testers don't send you reports about warnings produced by your module test suite on some version of Perl that you haven't used recently).

      Also, I've observed that, in general, warnings are usually pretty useless when delivered to somebody other than the author (or a maintainer) of the code most responsible for the warning. So putting 'use warnings;' in my module to force the display of warnings to people who merely make use of my module seems of little value (and, if having any consequence, is most likely to lead to annoyance).

      It is the rare case that I want to enable warnings only for a lexical scope and also have a good reason to avoid warnings from other lexical scopes (and so choose to not see warnings due to data leaking out of that scope).

      'no warnings ...;' is a feature I find quite useful. I may even write that more often than I write 'use warnings;', though still relatively rarely.

      - tye        

        No, better, precisely for the reason you listed --- using -w turns on warnings for code you did not write
Re: This code snippet causes Perl to SEGV
by dave_the_m (Monsignor) on Aug 21, 2012 at 21:57 UTC
    This appears to have been fixed for 5.12.0.

    Dave.

Re: This code snippet causes Perl to SEGV
by bulk88 (Priest) on Aug 21, 2012 at 20:32 UTC
    Tried it on my Visual C Perl 5.17.3. I got an X printed to console. No crash.
Re: This code snippet causes Perl to SEGV
by VinsWorldcom (Prior) on Aug 21, 2012 at 20:43 UTC

    No crash with Strawberry 5.16.1 on Windows 7 x64, just the aforementioned "X":

    VinsWorldcom@C:\Users\VinsWorldcom\tmp> perl -v This is perl 5, version 16, subversion 1 (v5.16.1) built for MSWin32-x +64-multi-thread Copyright 1987-2012, Larry Wall Perl may be copied only under the terms of either the Artistic License + or the GNU General Public License, which may be found in the Perl 5 +source kit. Complete documentation for Perl, including FAQ lists, should be found +on this system using "man perl" or "perldoc perl". If you have acces +s to the Internet, point your browser at http://www.perl.org/, the Pe +rl Home Page. VinsWorldcom@C:\Users\VinsWorldcom\tmp> perl test.pl X