Re: oddity in op.c
On Mon, Sep 19, 2005 at 11:31:19PM +0100, Nicholas Clark wrote:
Merijn notices this line in 5.8.x in S_new_logop
if ((type == OP_AND) == (SvTRUE(((SVOP*)first)-op_sv))) {
It's wonky. It seems to be wrong. But it's been that way since 5.8.0 started.
The corresponding point in blead is
if ((type == OP_AND SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_OR !SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_DOR !SvOK(((SVOP*)first)-op_sv))) {
This was patched by Marcus Holland-Moritz, changing that == to in the
process:
http://public.activestate.com/cgi-bin/perlbrowse?patch=22625
Presumably '==' is wrong. But if this is a bug, how can it be detected
with a perl level regression test?
== is correct; if both operands are 0 or 1, a == b is equivalent
to !(a ^ b) is equivalent to !(a !b || !a b) is equivlent to
a b || !a !b.
Re: oddity in op.c
what's OP_DOR?
Re: oddity in op.c
On 9/20/05, David Nicol [EMAIL PROTECTED] wrote: what's OP_DOR? //
Re: oddity in op.c
On 9/20/05, Rafael Garcia-Suarez [EMAIL PROTECTED] wrote:
On 9/20/05, David Nicol [EMAIL PROTECTED] wrote:
what's OP_DOR?
//
Now that defined-or has an opcode, is
if(defined(EXPR)){...
optimized to use it instead of calling OP_DEFINED?
--
David L Nicol
Abkey, deafghee, jekyll
minopker stoov wixes! -- Big Bird, 1973
Re: oddity in op.c
On 9/20/05, David Nicol [EMAIL PROTECTED] wrote:
what's OP_DOR?
//
Now that defined-or has an opcode, is
if(defined(EXPR)){...
optimized to use it instead of calling OP_DEFINED?
you mean unless(defined(EXPR)) surely... No, it's not, currently.
Re: oddity in op.c
On Tue, 20 Sep 2005 11:21:40 -0700, Yitzchak Scott-Thoennes
[EMAIL PROTECTED] wrote:
On Mon, Sep 19, 2005 at 11:31:19PM +0100, Nicholas Clark wrote:
Merijn notices this line in 5.8.x in S_new_logop
if ((type == OP_AND) == (SvTRUE(((SVOP*)first)-op_sv))) {
It's wonky. It seems to be wrong. But it's been that way since 5.8.0
started.
The corresponding point in blead is
if ((type == OP_AND SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_OR !SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_DOR !SvOK(((SVOP*)first)-op_sv))) {
This was patched by Marcus Holland-Moritz, changing that == to in the
process:
http://public.activestate.com/cgi-bin/perlbrowse?patch=22625
Presumably '==' is wrong. But if this is a bug, how can it be detected
with a perl level regression test?
== is correct; if both operands are 0 or 1, a == b is equivalent
to !(a ^ b) is equivalent to !(a !b || !a b) is equivlent to
a b || !a !b.
I just didn't understand why it was changed.
Changes like this (and the scattered const additions, thanks Andy) make
maintaining the dor patch take a lot of time. But it's in working order
again, and it still passes all tests :)
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11,
AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
reports to: [EMAIL PROTECTED],perl-qa@perl.org
oddity in op.c
Merijn notices this line in 5.8.x in S_new_logop
if ((type == OP_AND) == (SvTRUE(((SVOP*)first)-op_sv))) {
It's wonky. It seems to be wrong. But it's been that way since 5.8.0 started.
The corresponding point in blead is
if ((type == OP_AND SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_OR !SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_DOR !SvOK(((SVOP*)first)-op_sv))) {
This was patched by Marcus Holland-Moritz, changing that == to in the
process:
http://public.activestate.com/cgi-bin/perlbrowse?patch=22625
Presumably '==' is wrong. But if this is a bug, how can it be detected
with a perl level regression test?
Nicholas Clark
RE: oddity in op.c
On Mon, 19 Sep 2005, Nicholas Clark wrote:
Merijn notices this line in 5.8.x in S_new_logop
if ((type == OP_AND) == (SvTRUE(((SVOP*)first)-op_sv))) {
It's wonky. It seems to be wrong. But it's been that way since 5.8.0 started.
The corresponding point in blead is
if ((type == OP_AND SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_OR !SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_DOR !SvOK(((SVOP*)first)-op_sv))) {
This was patched by Marcus Holland-Moritz, changing that == to in the
process:
http://public.activestate.com/cgi-bin/perlbrowse?patch=22625
Presumably '==' is wrong. But if this is a bug, how can it be detected
with a perl level regression test?
If type can *only* be either OP_AND or OP_OR, then the code is actually
equivalent as far as I can tell. The second form is just more robust
in case type can assume any other value.
Cheers,
-Jan
