Open XRFXLP opened 3 years ago
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:
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.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.
@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?
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:
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.
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.
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?
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 .
Pascal (?)
It looks like Free Pascal comes with GMP.
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