develooper Front page | perl.perl5.porters | Postings from August 2001

Re: Where should a test for pp_divide behaviour go?

Thread Previous | Thread Next
Nicholas Clark
August 20, 2001 03:28
Re: Where should a test for pp_divide behaviour go?
Message ID:
On Mon, Aug 20, 2001 at 10:58:51AM +0100, Hugo van der Sanden wrote:
> Nicholas Clark <> wrote:
> :Currently pp_divide reads both operands from the stack before testing
> :the right operand to see if it is zero. This results in the following
> :behaviour:
> :
> :perl -wle 'print undef()/0'
> :Use of uninitialized value at -e line 1.
> :Illegal division by zero at -e line 1.
> :
> :Do we wish to preserve this?
> :Or is it fair to read the top argument from the stack, and if it is zero
> :die with "Illegal division" before even inspecting the second argument?
> Don't we need to look at the LHS to determine whether division is
> overloaded?

Yes. I wasn't clear. I was ignoring the expansion of
tryAMAGICbin(div,opASSIGN) in pp_divide. I was wondering more about the
body for the non-overloaded case:

    dSP; dATARGET; tryAMAGICbin(div,opASSIGN);
      NV value;
      if (right == 0.0)
	DIE(aTHX_ "Illegal division by zero");
      /* insure that 20./5. == 4. */
	IV k;
	if ((NV)I_V(left)  == left &&
	    (NV)I_V(right) == right &&
	    (k = I_V(left)/I_V(right))*I_V(right) == I_V(left)) {
	    value = k;
	else {
	    value = left / right;
      value = left / right;
      PUSHn( value );

where dPOPPOPnnrl has already defined two C variables and filled them
with NVs popped from the stack, and that popping of NVs will already have
triggered "Use of uninitialized value" errors.

Unlike pp_add, pp_subtract and pp_multiply, pp_divide doesn't currently
preserve 64 bit integers. I have a patch to do so that I'm currently testing,
and it would be possible to do the zero check before touching the left SV.
This would change the warnings issued in the corner case where the left
argument is uninitialized (or not a number)

> :Assuming we do wish to preserve current behaviour, where in which test
> :script should a test go? It's not obvious to me that it ought to be part
> :of warnings.t.
> Looks like a test of the presence/absence of a warning to me.

Which would be t/lib/warnings/sv ?
Except that that file currently tests only warnings generated in sv.c
*If* we decide that perl should maintain current behaviour, then a test
would be for a warning from sv.c and then a fatal error from pp.c, which
is a bit more messy than anything I can currently find in tests for

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About