I did, but it was resulting in a wide string... or so I thought. It turned out to be an L in front of a string being interpreted as a wide string marker.
How do I put in the special ... character in C?
The compiler keeps trying to make the string literal an int array, but that doesn't match the function return type and then the zero high bytes in the wide string get interpreted as '\0's.
An annoying but possible solution might be to make a custom int subclass that checks for oversized ints, pass in a RestrictedInt(10) along with n, and disallow integer literals
You'd also have to ban the use of int, __class__, type, and Decimal.
But that would make it harder than other languages...
Edit: oops; it would still be possible to break the integer restriction using any default method that returns an int
Too much work to replace all the builtins and ban all the importables that would return int...
Is this resolved?
I replaced the thrown exceptions with test.fail and the message except for the table one, but that one's caught an message'd in the table test.
Is this a reasonable translation? I used stack depth in bytes instead of counting frames.
I copied the anti-table measures as well, but I don't understand what they're combatting.
I did, but it was resulting in a wide string... or so I thought. It turned out to be an L in front of a string being interpreted as a wide string marker.
How do I put in the special ... character in C?
The compiler keeps trying to make the string literal an int array, but that doesn't match the function return type and then the zero high bytes in the wide string get interpreted as '\0's.
This comment is hidden because it contains spoiler information about the solution
A solution that needs space proportional to the input numbers' values won't be able to handle the random tests.
This comment is hidden because it contains spoiler information about the solution
according to
evcxr, which is a rust REPLThe translation it's forked from didn't pass its tests
Haskell Translation
An annoying but possible solution might be to make a custom int subclass that checks for oversized ints, pass in a RestrictedInt(10) along with n, and disallow integer literals
You'd also have to ban the use of
int,__class__,type, andDecimal.But that would make it harder than other languages...
Edit: oops; it would still be possible to break the integer restriction using any default method that returns an int
Too much work to replace all the builtins and ban all the importables that would return int...
Java has no BigInteger prevention test at the moment;
I made a fork to add one in: https://www.codewars.com/kumite/6519ffe580f7c47d2e82a74c?sel=6519ffe580f7c47d2e82a74c
Rust Translation
Is this resolved?
I replaced the thrown exceptions with test.fail and the message except for the table one, but that one's caught an message'd in the table test.
This comment is hidden because it contains spoiler information about the solution
Rust Translation
https://www.codewars.com/kumite/65054d57bc47bc00316babd1
Is this a reasonable translation? I used stack depth in bytes instead of counting frames.
I copied the anti-table measures as well, but I don't understand what they're combatting.
Loading more items...