Scala Programming Language
  1. Scala Programming Language
  2. SI-4370

Range bug: Wrong result for Long.MinValue to Long.MaxValue by Int.MaxValue

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Scala 2.11.1-RC1
    • Component/s: Misc Library
    • Labels:
    • Environment:

      range yetanotherbuginrange long maxvalue minvalue

      Description

      === What steps will reproduce the problem? ===

      Long.MinValue to Long.MaxValue by Int.MaxValue
      

      === What is the expected behavior? ===
      (2*9223372036854775807)/2147483647 = 8589934596
      and 8589934596 > Int.MaxValue.

      It should be rejected, because it has more than Int.MaxValue elements.

      === What do you see instead? ===

      scala.collection.immutable.NumericRange[Long] = NumericRange(-9223372036854775808)
      

      === Additional information ===
      I think Paul is the expert here, see SI-4308 and SI-4321.

      === What versions of the following are you using? ===

      • Scala: 2.10.0.r24516-b20110320020044

        Activity

        Hide
        Rex Kerr added a comment -

        The change in behavior is not intended.

        Another one: 0.0 until 0.3 by 0.1 does not give the expected result.

        Show
        Rex Kerr added a comment - The change in behavior is not intended. Another one: 0.0 until 0.3 by 0.1 does not give the expected result.
        Hide
        Daniel Darabos added a comment -

        I may have a fix for "0.0 until 0.3 by 0.1".

        I'm trying to fix https://issues.scala-lang.org/browse/SI-8518. I've added a test for it, and have a fix. It also fixes "0.0 until 0.3 by 0.1". Perhaps someone can help me sort out the binary incompatibility warnings? The changes are in:
        https://github.com/darabos/scala/commits/SI-8518

        Should I send this as a pull request even if it is unfinished?

        Show
        Daniel Darabos added a comment - I may have a fix for "0.0 until 0.3 by 0.1". I'm trying to fix https://issues.scala-lang.org/browse/SI-8518 . I've added a test for it, and have a fix. It also fixes "0.0 until 0.3 by 0.1". Perhaps someone can help me sort out the binary incompatibility warnings? The changes are in: https://github.com/darabos/scala/commits/SI-8518 Should I send this as a pull request even if it is unfinished?
        Hide
        Rex Kerr added a comment -

        It looks like the changes you are making can't go in 2.11 because they rely upon things that are not binary compatible (e.g. abstract class to private class), so this would be a fix for 2.12 at the earliest. I'd hold off submitting a PR against 2.11 until I have a go at fixing it in a binary-compatible way. I don't think we want range broken for the whole 2.11 series. I'll give it a try tomorrow.

        Show
        Rex Kerr added a comment - It looks like the changes you are making can't go in 2.11 because they rely upon things that are not binary compatible (e.g. abstract class to private class), so this would be a fix for 2.12 at the earliest. I'd hold off submitting a PR against 2.11 until I have a go at fixing it in a binary-compatible way. I don't think we want range broken for the whole 2.11 series. I'll give it a try tomorrow.
        Hide
        Daniel Darabos added a comment -

        It doesn't exactly rely on such changes, it's just me being clumsy. I've got a version now which only adds two new private methods. Still it is rejected by the forward binary compatibility check. I'm fairly new to all this — is there a common way to add some internal code in a way that passes the compatibility check?

        I appreciate you jumping on the problem right away! It's just that SI-8518 was broken in 2.10 too, so even if you fix this tomorrow, I still have to figure it out for my change. Thanks!

        Show
        Daniel Darabos added a comment - It doesn't exactly rely on such changes, it's just me being clumsy. I've got a version now which only adds two new private methods. Still it is rejected by the forward binary compatibility check. I'm fairly new to all this — is there a common way to add some internal code in a way that passes the compatibility check? I appreciate you jumping on the problem right away! It's just that SI-8518 was broken in 2.10 too, so even if you fix this tomorrow, I still have to figure it out for my change. Thanks!
        Hide
        Rex Kerr added a comment -

        Daniel Darabos I don't see how an anchor point is really going to solve the issues. The key is the comment "XXX This may be incomplete". This is a classic design bug pattern: inheritance that doesn't override enough to do what it needs to do. To solve the issue, we need to add overrides in mapRange's overridden NumericRange (and make sure it gets used).

        Show
        Rex Kerr added a comment - Daniel Darabos I don't see how an anchor point is really going to solve the issues. The key is the comment "XXX This may be incomplete". This is a classic design bug pattern: inheritance that doesn't override enough to do what it needs to do. To solve the issue, we need to add overrides in mapRange's overridden NumericRange (and make sure it gets used).

          People

          • Assignee:
            Rex Kerr
            Reporter:
            Simon Ochsenreither
            TracCC:
            Simon Ochsenreither
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development