• d-bugmail puremagic.com (19/20) Nov 25 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7006
• d-bugmail puremagic.com (18/22) Nov 27 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7006
• d-bugmail puremagic.com (12/12) Nov 28 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7006
• d-bugmail puremagic.com (13/23) Dec 02 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7006

d-bugmail puremagic.com writes:

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



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: -------

d-bugmail puremagic.com writes:

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


Don <clugdbug yahoo.com.au> changed:

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




 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: -------

d-bugmail puremagic.com writes:

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




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: -------

d-bugmail puremagic.com writes:

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





 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: -------