Katas concerned with Big integers computations have Obvious Flaws

[XRFXLP]

The most obvious "cheat" (here : solving by a means that was not intended) in these katas is that Node 10 or higher is enabled, making the whole kata and its ranking worthless.

Another bug is that construct which one can exploit to run shell commands are not disabled.
For instance : require in JS

[hobovsky]

I wanted to create a list of such kata, but having it in public would create a nice collection of blue kata with workarounds :) But indeed, there's quite a bunch of them.

There's more than one issue here:

1. Translations into languages with "not obvious" support of BigInteger arithmetic (java.math.BigInteger in Java, System.Numerics.BigInteger in C#): translators and approvers are not aware that the problem can be solved with a couple of additional imports.
2. Changes in a language which introduce biginteger arithmetic where it was not available before (Javascript and Node 10).
3. Translations into languages which obviously should not happen, because they directly support biginteger arithmetic (Python, Haskell, today also JS). For some reason, some translators created such translations, and some approvers approved them.
4. Languages which do not support any direct workaround, but the environment provides tools for that (for example C++ runner setup contains python interpreter).

I think that pt 4 is the easiest to address, because we can simply declare such solutions as cheats and flag them. It's difficult to require kata authors to protect from every possible abuse, and I think that calling an external command somewhat suits the definition of working around the testing framework.

Points 1. - 3. should be easy to handle during review, but they are more difficult to handle after approval. I think the only option currently available is enforcing some code restrictions, for example by inspecting the source code. Having a possibility to retire/suspend/remove/deactivate a translation from a kata would be helpful for scenarios like this one.

[hobovsky]

@kazk maybe you'd have some idea how to handle existing translations of biginteger kata? Is it possible for you do to some admin magic to disable affected translations?

[monadius]

It is already possible to "retire" some translations by adding something like assert(false) to tests and stating that the kata cannot be completed in specific languages in the description. In this way, all existing valid solutions are preserved and can be accessed after forfeiting a kata (it can be solved in valid languages first).

What is a complete list of languages for which biginteger kata make sense? My list is the following:

• BF (the encoding of input/output should be explicitly defined)
• C
• C++ (Python shenanigans should be somehow handled)
• Forth
• Fortran (?)
• Lua (?)
• NASM
• Objective-C
• Pascal (?)
• SQL (?, the encoding of input/output should be explicitly defined)
• Swift

[FArekkusu]

SQL (?, the encoding of input/output should be explicitly defined)

numeric in PostgreSQL can be arbitrarily long.

C++ (Python shenanigans should be somehow handled)

Any language where it's possible to run terminal is subjected to the same workaround, so I assume that half the languages from this list require an anticheat too.

[monadius]

SQL: Is this reference correct?

numeric: up to 131072 digits before the decimal point; up to 16383 digits after the decimal point

So it should be possible to create tests with millions of digits. But is PostgreSQL fast enough to handle such tests? In any case, I don't think SQL is a good language for biginteger kata.

[monadius]

FArekkusu is right. It seems that all containers have a Python interpreter and essentially all languages (except BF) can access it. It is always possible to prohibit Python explicitly in the description and penalize offenders manually. But is it possible to implement good anti-cheats in some languages from my list?

[XRFXLP]

It is always possible to prohibit Python explicitly in the description

Nothing special about python, one can always echo the source code into text file, then echo its output to another text file and read it from there.

>>> echo "print(4038086%45)" > src.rb
>>> ruby src.rb > output.txt
>>> File.open('output.txt').read
11

---

BTW This is quite general "hack" not necessarily limited to Big integer katas .

[error256]

Pascal (?)

It looks like Free Pascal comes with GMP.