worenklein has asked for the wisdom of the Perl Monks concerning the following question:
#!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): 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 | [reply] [Watch: Dir/Any] [d/l] |
Re: This code snippet causes Perl to SEGV
by FunkyMonk (Chancellor) on Aug 21, 2012 at 22:13 UTC | |
The code runs fine on Ubuntu & perl 5.10.1 if you remove the pre-declared prototype (sub foo();). You don't need prototypes. They very probably don't do whatever it is you think they do. Update: This works for me on 5.10.1. Try it on your 5.10.0:
I've been doing a lot of Python recently. Semi-colons sure do look weird now :) | [reply] [Watch: Dir/Any] [d/l] [select] |
Re: This code snippet causes Perl to SEGV
by Marshall (Canon) on Aug 21, 2012 at 20:29 UTC | |
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. | [reply] [Watch: Dir/Any] |
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 | [reply] [Watch: Dir/Any] |
by tye (Sage) on Aug 22, 2012 at 01:23 UTC | |
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 | [reply] [Watch: Dir/Any] [d/l] [select] |
by Anonymous Monk on Aug 22, 2012 at 02:47 UTC | |
| [reply] [Watch: Dir/Any] |
Re: This code snippet causes Perl to SEGV
by dave_the_m (Monsignor) on Aug 21, 2012 at 21:57 UTC | |
Dave. | [reply] [Watch: Dir/Any] |
Re: This code snippet causes Perl to SEGV
by bulk88 (Priest) on Aug 21, 2012 at 20:32 UTC | |
| [reply] [Watch: Dir/Any] |
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":
| [reply] [Watch: Dir/Any] [d/l] |