http://d.puremagic.com/issues/show_bug.cgi?id=7006

           Summary: std.math.pow (integral, integral) crashes on negative
                    exponents
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: timon.gehr@gmx.ch


--- Comment #0 from timon.gehr@gmx.ch 2011-11-25 13:12:07 PST ---
It seems to be by design:
> if (n<0) return x/0; // Only support positive powers

But that does not make any sense. The results are well-defined if x!=0.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7006


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2011-11-27 23:36:13 PST ---
(In reply to comment #0)
> It seems to be by design:
> > if (n<0) return x/0; // Only support positive powers
> 
> But that does not make any sense. The results are well-defined if x!=0.

No, they aren't well defined. The result doesn't fit into an integer, unless x is 1 or -1.   x^^n is always a bug if x is an integer other than +-1, and n is a negative integer.

The idea behind the division by zero error is that some processors (such as x86) also give a div by zero error on -1 / (-1 - int.max), because the result isn't representable as an integer. It's ugly though.

Now that we have proper range checking, we should be able to statically disallow it, and make n unsigned.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7006



--- Comment #2 from timon.gehr@gmx.ch 2011-11-28 05:16:50 PST ---
That is like saying 1/2 should give a div by zero error because the result does not fit in an integer and therefore it must always indicate a bug.

I want this:

assert(a ^^ -1 == 1/a);

This is only div by zero if a is zero.


(BTW: This does not give a div by zero error on my x86 machine, and I have no
clue why you think it should: void main(){auto x = -1; x = x/(x-int.max);})

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7006



--- Comment #3 from Don <clugdbug@yahoo.com.au> 2011-12-02 05:01:01 PST ---
(In reply to comment #2)
> That is like saying 1/2 should give a div by zero error because the result does not fit in an integer and therefore it must always indicate a bug.

Accidental use of integer division instead of floating point division is a very, very common bug.

> I want this:
> 
> assert(a ^^ -1 == 1/a);

Why do you want that? Do you have any use cases where it's not a bug?

> This is only div by zero if a is zero.
> 
> 
> (BTW: This does not give a div by zero error on my x86 machine, and I have no
> clue why you think it should: void main(){auto x = -1; x = x/(x-int.max);})

Sorry, got it upside down. It's -int.max -1, divided by -1.
This generates a hardware division error. Depending on the OS, your OS may
inspect the operands to determine if it is a div by zero, or this special case:

void main(){auto x = 1; x = (-1-int.max)/-x;}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------