[BUG 5.005_60 & 5.005_03] == reported as eq in S_not_a_number

[p5pRT]

Migrated from rt.perl.org#1227 (status was 'resolved')

Searchable as RT1227$

[p5pRT]

From @schwern

Now that's just downright confusing. Same problem with all the other
numeric comparison operators.

I've traced the problem down to S_not_a_number() and how it calls
PL_op_name[PL_op->op_type] on Perl_warner.

PL_op_name being an array defined in opcode.h built off of information
in opcode.pl. opcode.pl says that "numeric eq" is "eq". Now that's
now right, but I think lots of things would suddenly break if I tried
to put "==" into the __DATA__ section of opcode.pl... "OP_==" would kinda
confuse C.

So it might be necessary to add a new field to the op code list
showing an operator's "real" representation.

I will ponder.

[p5pRT]

From [Unknown Contact. See original ticket]

Michael G Schwern writes​:

$ perl -wle '(1 == "")'
Argument "" isn't numeric in eq at -e line 1.

Now that's just downright confusing. Same problem with all the other
numeric comparison operators.

I've traced the problem down to S_not_a_number() and how it calls
PL_op_name[PL_op->op_type] on Perl_warner.

PL_op_name being an array defined in opcode.h built off of information
in opcode.pl. opcode.pl says that "numeric eq" is "eq". Now that's
now right, but I think lots of things would suddenly break if I tried
to put "==" into the __DATA__ section of opcode.pl... "OP_==" would kinda
confuse C.

So it might be necessary to add a new field to the op code list
showing an operator's "real" representation.

Try changing PL_op_name[PL_op->op_type] to PL_op_desc[...], test, and
send a patch.

Thanks,
Ilya

[p5pRT]

From @schwern

On Tue, Aug 17, 1999 at 05​:54​:23PM -0400, Ilya Zakharevich wrote​:

Michael G Schwern writes​:

PL_op_name being an array defined in opcode.h built off of information
in opcode.pl. opcode.pl says that "numeric eq" is "eq". Now that's
now right, but I think lots of things would suddenly break if I tried
to put "==" into the __DATA__ section of opcode.pl... "OP_==" would kinda
confuse C.

So it might be necessary to add a new field to the op code list
showing an operator's "real" representation.

Try changing PL_op_name[PL_op->op_type] to PL_op_desc[...], test, and
send a patch.

K, got it. Had to modify sv.c and the pragma/warning tests.

I think I'm going to hack on this issue a little bit more. Some of
the descriptions are kinda weak and could use some work (like, instead
of saying "addition", perhaps, "addition (+)" would be more
descriptive), and there's probably other places where PL_op_name is
used instead of PL_op_desc.

Here's the simplistic patch. Hold off on putting this in, I'll
probably have a better one soon.

*** sv.c 1999/08/17 22​:00​:48
--- sv.c 1999/08/17 22​:00​:53
***************
*** 1063,1069 ****
 
  if (PL_op)
  Perl_warner(aTHX_ WARN_NUMERIC, "Argument \"%s\" isn't numeric in %s", tmpbuf,
! PL_op_name[PL_op->op_type]);
  else
  Perl_warner(aTHX_ WARN_NUMERIC, "Argument \"%s\" isn't numeric", tmpbuf);
  }
--- 1063,1069 ----
 
  if (PL_op)
  Perl_warner(aTHX_ WARN_NUMERIC, "Argument \"%s\" isn't numeric in %s", tmpbuf,
! PL_op_desc[PL_op->op_type]);
  else
  Perl_warner(aTHX_ WARN_NUMERIC, "Argument \"%s\" isn't numeric", tmpbuf);
  }

*** t/pragma/warning.t 1999/08/17 22​:13​:40
--- t/pragma/warning.t 1999/08/17 22​:32​:13
***************
*** 30,35 ****
--- 30,38 ----
 
  next if /(~|\.orig)$/;
 
+ # Avoid stray RCS files.
+ next if /,v$/;
+
  open F, "<$_" or die "Cannot open $_​: $!\n" ;
  while (<F>) {
  last if /^__END__/ ;

*** t/pragma/warn/sv 1999/08/17 22​:18​:32
--- t/pragma/warn/sv 1999/08/17 22​:24​:05
***************
*** 185,191 ****
  no warning 'numeric' ;
  my $c = 1 + $a;
  EXPECT
! Argument "def" isn't numeric in add at - line 6.
  ########
  # sv.c
  use warning 'numeric' ;
--- 185,191 ----
  no warning 'numeric' ;
  my $c = 1 + $a;
  EXPECT
! Argument "def" isn't numeric in addition at - line 6.
  ########
  # sv.c
  use warning 'numeric' ;
***************
*** 193,199 ****
  no warning 'numeric' ;
  my $z = 1 + "def" ;
  EXPECT
! Argument "def" isn't numeric in add at - line 3.
  ########
  # sv.c
  use warning 'numeric' ;
--- 193,199 ----
  no warning 'numeric' ;
  my $z = 1 + "def" ;
  EXPECT
! Argument "def" isn't numeric in addition at - line 3.
  ########
  # sv.c
  use warning 'numeric' ;
***************
*** 202,208 ****
  no warning 'numeric' ;
  my $y = 1 + $a ;
  EXPECT
! Argument "def" isn't numeric in add at - line 4.
  ########
  # sv.c
  use warning 'numeric' ; use integer ;
--- 202,208 ----
  no warning 'numeric' ;
  my $y = 1 + $a ;
  EXPECT
! Argument "def" isn't numeric in addition at - line 4.
  ########
  # sv.c
  use warning 'numeric' ; use integer ;
***************
*** 211,217 ****
  no warning 'numeric' ;
  my $z = 1 + $a ;
  EXPECT
! Argument "def" isn't numeric in i_add at - line 4.
  ########
  # sv.c
  use warning 'numeric' ;
--- 211,217 ----
  no warning 'numeric' ;
  my $z = 1 + $a ;
  EXPECT
! Argument "def" isn't numeric in integer addition at - line 4.
  ########
  # sv.c
  use warning 'numeric' ;
***************
*** 219,225 ****
  no warning 'numeric' ;
  my $z = 1 & "def" ;
  EXPECT
! Argument "def" isn't numeric in bit_and at - line 3.
  ########
  # sv.c
  use warning 'redefine' ;
--- 219,225 ----
  no warning 'numeric' ;
  my $z = 1 & "def" ;
  EXPECT
! Argument "def" isn't numeric in bitwise and at - line 3.
  ########
  # sv.c
  use warning 'redefine' ;

--

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

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue, Aug 17, 1999 at 06​:35​:45PM -0400, Michael G Schwern wrote​:

I think I'm going to hack on this issue a little bit more. Some of
the descriptions are kinda weak and could use some work (like, instead
of saying "addition", perhaps, "addition (+)" would be more
descriptive), and there's probably other places where PL_op_name is
used instead of PL_op_desc.

Please send changes like "addition (+)" in a different patch, since they are

  a) orthogonal
  b) have a high probability to be controvertial;

Thanks for your work,
Ilya