Mailing List Archive: Expression -> string conversion bug?

Expression -> string conversion bug?

marting at igly

Nov 21, 1995, 12:14 PM

Post #1 of 6 (350 views)

Appended is a short perl script. It produces a different output
depending on whether you use perl4.036 or perl5.001m. I would be
interested to hear an explanation of why this is so, and why the perl5
behaviour is not a bug if it is not, because it is certainly not what
I would have expected.

Note that if you don't include the $c in the expressions then the
output of perl4 and perl5 are the same!

Thanks for your help.

Martin

----------------------------------------------------------------------
#! /usr/bin/perl -w

$a = 0;
$b = 1;
$c = 0;

$tester = "result:";

$tester .= (!$a && !$b && !$c); # if you use (!$a && !$b) in these, then
$tester .= ($a && $b && $c); # there is no difference perl4 <-> perl5

print "$tester\n";
----------------------------------------------------------------------

With perl 4 I get:

result:00

With perl 5 I get:

result:0

Que?

[This was posted to comp.lang.perl.misc but got no response :-( ]

Re: Expression -> string conversion bug? [ In reply to ]

lwall at scalpel

Nov 21, 1995, 11:40 AM

Post #2 of 6 (340 views)

: With perl 5 I get:
:
: result:0
:
: Que?

The ! operator returns "" for false in Perl 5. It one of those places
where Perl 5 was regularized a bit. One many architectures the ""
value is a little faster to test for trueness than a numeric value.

On the other hand, it might have been an accident... :-)

Larry

Re: Expression -> string conversion bug? [ In reply to ]

kjahds at kjahds

Nov 21, 1995, 5:38 PM

Post #3 of 6 (337 views)

On Tue, 21 Nov 1995, Larry Wall wrote:

> : With perl 5 I get:
> :
> : result:0
> :
> : Que?
>
> The ! operator returns "" for false in Perl 5. It one of those places
> where Perl 5 was regularized a bit. One many architectures the ""
> value is a little faster to test for trueness than a numeric value.

This one caught me by suprise the other day. I used "!! expr" to
regularlize the expression to a boolean, and had wasn't expected "" as
the output on 0.

> On the other hand, it might have been an accident... :-)
>
> Larry
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

Re: Expression -> string conversion bug? [ In reply to ]

h.b.furuseth at usit

Nov 22, 1995, 7:18 AM

Post #4 of 6 (336 views)

> Any statements that used to be
>
> $string .= expression_using_negation;
>
> now has to be
>
> $string .= expression_using_negation ? '1' : '0';

Well, Almost. (expression_using_negation || '0') is enough.

Regards,

Hallvard

Re: Expression -> string conversion bug? [ In reply to ]

lwall at scalpel

Nov 22, 1995, 9:29 AM

Post #5 of 6 (343 views)

: > Any statements that used to be
: >
: > $string .= expression_using_negation;
: >
: > now has to be
: >
: > $string .= expression_using_negation ? '1' : '0';
:
: Well, Almost. (expression_using_negation || '0') is enough.

Or (expression_using_negation + 0). Though yours may be more efficient.

Larry

Re: Expression -> string conversion bug? [ In reply to ]

marting at igly

Nov 22, 1995, 10:00 AM

Post #6 of 6 (336 views)

>>>>> "Larry" == Larry Wall <lwall@scalpel.netlabs.com> writes:

Larry> : With perl 5 I get:
Larry> :
Larry> : result:0
Larry> :
Larry> : Que?

Larry> The ! operator returns "" for false in Perl 5. It one of
Larry> those places where Perl 5 was regularized a bit. One many
Larry> architectures the "" value is a little faster to test for
Larry> trueness than a numeric value.

Larry> On the other hand, it might have been an accident... :-)

You mean that the length of the result of the ! operator is no longer
constant?

Hmmm.. this seems like a nasty sort of accident to me, from my
admittedly narrow perspective. It means you can no longer print out
the result of a test, or put it in a string, without actually checking
whether it contains 1 or zero characters. UGH!

IE Any statements that used to be

$string .= expression_using_negation;

now has to be

$string .= expression_using_negation ? '1' : '0';

Is the uncertainty worth the "regularisation" you mention, one has to wonder?

Cheers,

Martin.