FAQ
Encountered a couple things which I consider bugs:

1. die [1,2];
This causes a core dump. I'm very pleased that Perl now supports
non-string data in $@, but less pleased that it crashes. Perhaps it would be
nice if the default code that prints out the contents of $@ would check and
see if it was an object with a toString method, and then call that to get a
textual message to display.
Perhaps it would be nice if Perl did this for all reference types before
displaying them. Lot's of things would be nice. Having all reference types
be objects would be nice.
I considered using $SIG{__DIE__} to address this, but as I cannot figure
out what people seem to think is wrong with that, I am avoiding it. Of
course, before it was mentioned here, I would not have even thought about
using it.

2. local($HASH{KEY});
This causes the key to exist in the table when the scope returns even if
it did not exist before this line of code executed. While using local(%HASH)
can be used to preserve such existence throughout the hash, it is not
generally the best thing to do.


And other comments on Perl:

A. There appears to be no straightforward way to test if SV* is defined or
not. I am using ( SvTYPE == SVt_NULL ), but I have no idea if that is right.

B. It would be nice if the default typemap entry for converting to a char*
(and variants thereof) would automatically convert undefined input to NULL,
rather than (I presume) to an empty string. Generic pointer types (T_PTR)
are converted to NULL (by being converted to 0), so this would seem
reasonable to me. For now, I am doing this myself (thus raising point "A").


--
John Redford
AKA GArrow

Search Discussions

  • Gurusamy Sarathy at Oct 2, 1999 at 1:16 am

    On Fri, 01 Oct 1999 20:23:38 EDT, "Redford, John" wrote:
    And other comments on Perl:

    A. There appears to be no straightforward way to test if SV* is defined or
    not.
    For scalar types (which are the only ones defined() is useful for
    typically):

    SvOK(sv) ? "defined" : "undef";


    Sarathy
    gsar@activestate.com
  • Redford, John at Oct 2, 1999 at 3:45 am
    That test seems to work if I want to tell the difference between
    foo(undef);
    and
    foo($scalar);

    But when I run:
    $scalar = undef;
    foo($scalar);
    SvOK says "defined".

    I need to tell if the "evaluated value" is undef or not, not the literal
    variable/constant.

    When I started looking for SvDEFINED (which obviously does not exist), I
    immediately wondered if there were some natural way to directly invoke the C
    functions which implement the Perl core (as I noticed that the code for
    "defined" was non-trivial). I quickly guessed "no way in hell". Being picky,
    I would only be happy with a simple "PERLOP_CALL(OP_DEFINED, sv);", not a
    technique involving half a dozen calls to macros and setting up the stack by
    hand. Anyway, perhaps this is already possible and I simply haven't read the
    documentation.

    (I didn't mention it before, but these comments are all WRT 5.005_02).
    -----Original Message-----
    From: Gurusamy Sarathy [SMTP:gsar@activestate.com]
    Sent: Friday, October 01, 1999 9:21 PM
    To: Redford, John
    Cc: perl5-porters@perl.org
    Subject: Re: Bugs and Comments
    On Fri, 01 Oct 1999 20:23:38 EDT, "Redford, John" wrote:
    And other comments on Perl:

    A. There appears to be no straightforward way to test if SV* is defined or
    not.
    For scalar types (which are the only ones defined() is useful for
    typically):

    SvOK(sv) ? "defined" : "undef";


    Sarathy
    gsar@activestate.com
  • Gurusamy Sarathy at Oct 2, 1999 at 4:08 am

    On Fri, 01 Oct 1999 23:45:22 EDT, "Redford, John" wrote:
    That test seems to work if I want to tell the difference between
    foo(undef);
    and
    foo($scalar);

    But when I run:
    $scalar = undef;
    foo($scalar);
    SvOK says "defined".
    It is supposed to work for that. There's probably something about
    $scalar that you're not telling us. Is it tied by any chance?

    I know that because Data::Dumper uses SvOK() to test definedness, and
    you can see it works fine:

    % perl -MData::Dumper=DumperX -we '$x = undef; print DumperX($x)'
    $VAR1 = undef;
    I need to tell if the "evaluated value" is undef or not, not the literal
    variable/constant.
    If $scalar happens to be tied, you'll need to do a mg_get() on it
    beforehand.


    Sarathy
    gsar@activestate.com
  • Redford, John at Oct 3, 1999 at 2:40 pm
    Nothing was ever tied...

    SvOK is working fine for me now. I must have had some kind of serendipitous
    bug.

    Any comments on the other three points? Primarily, did I encounter a "freak
    feature" when using a reference in $@, or has this been documented somewhere
    as being a genuine planned bit of Perl?
    -----Original Message-----
    From: Gurusamy Sarathy [SMTP:gsar@activestate.com]
    Sent: Saturday, October 02, 1999 12:14 AM
    To: Redford, John
    Cc: 'Gurusamy Sarathy'; perl5-porters@perl.org
    Subject: Re: Bugs and Comments
    On Fri, 01 Oct 1999 23:45:22 EDT, "Redford, John" wrote:
    That test seems to work if I want to tell the difference between
    foo(undef);
    and
    foo($scalar);

    But when I run:
    $scalar = undef;
    foo($scalar);
    SvOK says "defined".
    It is supposed to work for that. There's probably something about
    $scalar that you're not telling us. Is it tied by any chance?

    I know that because Data::Dumper uses SvOK() to test definedness, and
    you can see it works fine:

    % perl -MData::Dumper=DumperX -we '$x = undef; print DumperX($x)'
    $VAR1 = undef;
    I need to tell if the "evaluated value" is undef or not, not the literal
    variable/constant.
    If $scalar happens to be tied, you'll need to do a mg_get() on it
    beforehand.


    Sarathy
    gsar@activestate.com
  • Gurusamy Sarathy at Oct 3, 1999 at 4:52 pm

    On Sun, 03 Oct 1999 10:39:56 EDT, "Redford, John" wrote:
    Any comments on the other three points? Primarily, did I encounter a "freak
    feature" when using a reference in $@, or has this been documented somewhere
    as being a genuine planned bit of Perl?
    The only genuine planned coredump that you get from Perl would be the
    one from dump(). :-)

    C<die [1,2]> doesn't cause a coredump with what I have (5.005_61+).
    I'd suggest trying 5.005_03--I recall a related fix was in there too.

    L<perlsub/"Temporary values via local()"> is relevant for your issue
    with C<local $foo{nothere}>.

    On undefined values converting to NULL in the typemaps for char*,
    I'd say it would be a compatibility issue to change something like
    that now. We could add a new typemap entry with the behavior you
    want though. Want to write a patch for it?


    Sarathy
    gsar@activestate.com
  • Chris Nandor at Oct 3, 1999 at 5:31 pm

    At 9:57 -0700 1999.10.03, Gurusamy Sarathy wrote:
    C<die [1,2]> doesn't cause a coredump with what I have (5.005_61+).
    I'd suggest trying 5.005_03--I recall a related fix was in there too.
    I saw the same core dump in 5.005_02, FWIW. I don't have an _03 handy.

    --
    Chris Nandor mailto:pudge@pobox.com http://pudge.net/
    %PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
  • M.J.T. Guy at Oct 4, 1999 at 1:11 pm
    Gurusamy Sarathy wrote
    C<die [1,2]> doesn't cause a coredump with what I have (5.005_61+).
    I'd suggest trying 5.005_03--I recall a related fix was in there too.

    I can confirm that here it fails SEGV under 5.005_02 and is OK under
    5.005_03.

    This isn't the first time that I've commented that it was a mistake
    to announce 5.005_02 as "stable". But that's ancient history now.


    Mike Guy
  • Gurusamy Sarathy at Oct 4, 1999 at 3:41 pm

    On Mon, 04 Oct 1999 14:11:52 BST, "M.J.T. Guy" wrote:
    This isn't the first time that I've commented that it was a mistake
    to announce 5.005_02 as "stable". But that's ancient history now.
    FWIW, I beg to differ. 5.005_02 has been more "stable" than all
    other previous releases of perl I've worked with. (The only serious
    new bug to non-experimental features I'm aware of in 5.005_02 was
    the "return inside foreach" thing.)

    Stability can never be an absolute--it is by its very nature a
    retrospective notion.


    Sarathy
    gsar@activestate.com
  • Michael G Schwern at Oct 11, 1999 at 7:10 pm

    On Sunday, 3 Oct 1999 13:30:51 -0400 Pudge was said to have uddered:
    At 9:57 -0700 1999.10.03, Gurusamy Sarathy wrote:
    C<die [1,2]> doesn't cause a coredump with what I have (5.005_61+).
    I'd suggest trying 5.005_03--I recall a related fix was in there too.
    I saw the same core dump in 5.005_02, FWIW. I don't have an _03 handy.
    die [1,2] works okay with 5.004_05, 5.005_03, 5.005_57, 5.005_60 and
    5.005_61, no core.

    --

    Michael G Schwern schwern@pobox.com
    http://www.pobox.com/~schwern
    /(?:(?:(1)[.-]?)?\(?(\d{3})\)?[.-]?)?(\d{3})[.-]?(\d{4})(x\d+)?/i

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedOct 2, '99 at 12:24a
activeOct 11, '99 at 7:10p
posts10
users5
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase