Say README suggests to test -1 but the unit tests expect uint64

[shaleh]

No description provided.

[shaleh]

Further, the README says code should report any values that are out of range. But Say takes a uint64. So negatives are not possible. If the input is larger than max unsigned 64-bit the value will wrap before the function ever sees it. Input validation is a total red herring.

[robphoenix]

Thanks @shaleh

[MatForsberg]

I believe since the instructions say any number from 0 to 999,999,999,999 and an uint64's max value is 18,446,744,073,709,551,615 that the request to report values out range refers to number from 1,000,000,000,000 to 18,446,744,073,709,551,615. A negative number would however cause an error in go. In rewriting this README would it be best to clarify the out of range testing or to just remove it along with the suggestion to test with -1?

[shaleh]

Actually,since this is one of the earlier problems perhaps switch back to a standard signed int would be the right thing to do? This way the user gets to implement input validation. The current tests validate that ANY number that a uint64 can hold will work. Which directly contradicts the README since -1 can't be an input and numbers bigger than 1,000,000,000,000 are explicitly checked and expected to work.

Otherwise, document that no validation needs to be done and expect anything up to math.MaxUint64.

[robphoenix]

perhaps switch back to a standard signed int would be the right thing to do?

I agree with @shaleh here, I think say should use an int64. This would bring it in line with the canonical-data.json. I see no reason why this track should diverge from this. We should then update the test cases, and eventually implement a test generator, to reflect this.

[tleen]

Closed via 3e89b2c