in reply to String comparison "\x00" vs. "".

Is this somehow configuration dependent(like encoding or something) and only happens on my system?

No. It is the way it is.

  1. A string containing a char, even a char with the ordinal value of zero (aka. null), has a length of 1 char and so is true.
  2. Whereas a string that contains no chars, length 0, is false.

There are some exceptions to 1 above. If the character contained is numerically zero, then despite having length, the string will conditionally test as false. This is the compromise of "typeless languages" that makes everything work.

And then there are (the celebrated) exceptions to the exception, like "0e0" (& "0e-0" & ... ) that the 'type safety' people hate, but that help make the world go around.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^2: String comparison "\x00" vs. "".
by herveus (Prior) on Jun 08, 2010 at 11:13 UTC
    Howdy!

    ...not to mention the ever popular "0 but true"...

    yours,
    Michael
[reply]
Re^2: String comparison "\x00" vs. "".
by JavaFan (Canon) on Jun 08, 2010 at 11:19 UTC
    There are some exceptions to 1 above. If the character contained is numerically zero, then despite having length, the string will conditionally test as false.
    ...
    And then there are (the celebrated) exceptions to the exception, like "0e0" (& "0e-0" & ... ) that the 'type safety' people hate, but that help make the world go around.
    There are only exceptions to the exception because of you convoluted way of writing what is false. If you state it as:

    An expression is false if it (in scalar context -- boolean context is scalar context) evaluates to any of the following:

    • The undefined value.
    • Numerically 0.
    • The empty string.
    • The string "0".
    No exceptions. No exceptions to exceptions. And it has nothing to do with types.

    Update: if a variable has both string and numerical values, then the truth value of the string part wins: 

    use Scalar::Util 'dualvar';
my $p1 = dualvar 0, "foo";   # True
my $p2 = dualvar 1, "";      # False

    [download]
[reply]
[d/l]
[select]

      Overloaded bjects and tied variables can be false, and they're none of those.

      An expression is false if it stringifies to any of the following:

      • ""
      • "0"

      That includes undef and numerical zero. (It might fail for very tiny floats and weird dualvars, but it gives a good idea.)

[reply]
[d/l]
        An expression is false if it stringifies to any of the following
        But it wouldn't be Perl if there wasn't an exception to that: 
        use overload "bool" => sub {0},
             '""' => sub {"Send in the clowns"};
my $o = bless [];    # $o stringifies to "Send in the clowns"
say "Hello" if  $o;  # No stringification happening here
say "world" if "$o"; # Forced stringification

        [download]
        prints just "world"
[reply]
[d/l]
      No exceptions. No exceptions to exceptions. And it has nothing to do with types.

      Utter ribald twaddle!

      I said: "There are some exceptions to 1 above.". And in that context, the rest of what I said is completely accurate.

      I didn't set out to define what is false, just answer the OPs question.

      If you follow a set of directions, but start at a completely different place, you will end up getting lost in your own confusion.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom