in reply to Re: dumb question
in thread post-increment and post-decrement behavior (was: dumb question)

Your suggestion to turn on -w is absolutely right, but we should right the way apply it in this particular case.

Just a small correction ;-) For $a--, you said, "undef prints as the empty string", that's not quite right. The fact is Perl didn't print anything, and simply ignored that print $a--, because it attempted to print an uninitialized value.

This would become clear, if you try this:

Step 1:

Put this in a file, say test.pl: 
print $a--;

[download]
Step 2:

Run it by typing perl -w test.pl, and you will get the warning, so perl never printed it as empty string, instead issued a waring. However when you run it as one-liner, the warning is not printed.

So the bug (inconsistancy) is not that, in the -- case, perl see $a as string; in the ++ case, perl see $a as number.

The bug (inconsistancy) is that, in the -- case, perl straightly realized $a is uninitialized; in the ++ case, perl initialized it to 0.

Replies are listed 'Best First'.
Re: Re: Re: dumb question
by jand (Friar) on Mar 16, 2003 at 05:52 UTC
    No, that is not correct. Perl still "printed" the undef value as an empty string, it did not abort the print function just because a value was undefined. You could see this with e.g. 
    print $a--, "foo";

    [download]
    to see that you get both the warning and that "foo" is printed. But since printing an empty string is the same as not printing anything, it doesn't make much sense to argue this too long. :)
[reply]
[d/l]
      Okay this is my last post in this thread. ;-)

      From a pure logic point of view, answer yourself this questions (if you don't oppose, only whisper the answer to yourself, so we come to an end of this thread ;-), but any way, this is my last post, as I don't believe any more value can be yielded, I expressed whatever I think right, and so did you ;-) My question:

      When your example looks agree with your conclusion that $a is printed as empty string, WHAT MAKES YOU THINK IT DOES NOT AGREE WITH MY CONCLUSION THAT $a IS SIMPLY IGNORED, AND A WARNING IS PRINTED?
[reply]
        WHAT MAKES YOU THINK IT DOES NOT AGREE WITH MY CONCLUSION THAT $a IS SIMPLY IGNORED, AND A WARNING IS PRINTED?
        Well, we can rely on the declared principle that warnings do not change anything about the execution of the program. Other than additional output to STDERR (and in the absence of a $SIG{__WARN__}, which this program clearly does not have), a program will always run identically whether warnings are on or off. Warnings do not change program execution flow. They merely turn on additional debugging output.

        Second, we can test whether print actually "printed" in two ways. First, it'll return a true value indicating a "successful" print to an open filehandle with no I/O error. Second, we can alter something like $\ to add additional text to the print. I'm sure if you do either of those, you'll see that the undef was treated as the empty string, a warning was sent to STDERR, and the print completed its task. The print was not aborted.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

[reply]
        It is ignored the same way as "" is ignored in: 
            print "";

        [download]
        Technically "" isn't being ignored, but the effect is as if it was ignored because this statement was a no-op to start with.
[reply]
[d/l]

In Section Seekers of Perl Wisdom