Platform specific test failures

[rob-ross]

Did you encounter any Python specific issues in any of the test cases in your multiple public test suites? I'm failing the test for allowable index values because Java only provides for 32 bit unsigned values whereas JSON allows far larger ranges (+/- 2**53-1) . So my Java code will first report out-of-range JSON index errors, then immediately checks for out-of-range Java indexes. Therefore many of these tests in cts.json will always fail.

How did you handle these kinds of test issues ? Do you just keep them in a skip list forever? That means my "official" build will always indicate there were skipped tests. This doesn't feel like a proper solution. And if I manually remove them from the cts.json file, that becomes a maintenance issue when new versions of the file are published.

• Rob

[jg-rp]

Did you encounter any Python specific issues in any of the test cases in your multiple public test suites?

No, but then I'm not testing on 32 bit machines/builds. As far as I know, an out of range index would raise the same IndexError that I'm already suppressing, so it would silently select nothing, which would still pass the CTS tests.

How did you handle these kinds of test issues?

I would maintain a skip list and document the implementation's limitations.

---

Python seems to handle these things naturally, but sometimes I check array bounds explicitly when resolving a selector, like in Ruby.

norm_index = normalize(@index, node.value.length)
return [] if norm_index.negative? || norm_index >= node.value.length

Or in JavaScript.

const normIndex = this.normalizedIndex(node.value.length);
if (normIndex in node.value) { ... }

Taking the same approach in Java, you might need to store indexes as longs or BigIntegers internally, for the benefit of canonical paths, then just select nothing if the index can't be cast to an integer, considering no array will ever have that many items.

[rob-ross]

That's a great tip! Thanks. I've been using long ints (64 bits) to hold int Number values when lexing and parsing, and down casting to an int when I create a Slice or Index selector. I don't think I need BigInteger for these selectors though, since a long can hold any spec int value (+/-) 2**53-1. And I wanted to avoid extra boxing/unboxing steps for performance reasons.

You've also made me realize that there's no need to restrict the size of float or int literals used in other contexts, like comparisons. So for those maybe I'll have a number literal subclass for values outside the range of long or double, and use BigInteger and BigDecimal for those values.

I've already had to write special case comparison code to get 0 == -0. -0 can't be represented as an int or Integer in Java. It's actually a floating point value, which has the ability to have signs for zero. But 0 != -0 when strictly comparing, because they are different data types and equals() is using exact class comparison, which always returns false when comparing Integer to Double (float). Even comparing two floats, 0, -0 , returns false because they have different signs.

It's amazing how one little character in a language grammar can cause so many headaches!