I believe there is a general dislike of katas with source code restrictions among power users on Codewars (with the exception of code golf, as the byte size of the source file is something that is both easy to check and hard to fake without using techniques that would get one banned) because those restrictions are hard to enforce and require very complex test suites that are hard to maintain. Some users will come up with very clever ways of bypassing them, which means the katas have to be patched regularly, which is a maintenance hassle. This is especially true in dynamic languages such as Python and JavaScript. C is different, but has its own specific loopholes due to its low-level nature.
In some such katas it's somewhat more manageable as the there is a single thing banned (e.g. alphanumeric characters, if and '?', %, digits) that are very easy to scan for in the source code. But in the current kata many things need to be banned, which makes it more complicated.
As far as I know, checking the shared object dependencies / symbol table for anti-cheat purposes has never been done on Codewars, but I do not think it would be worth the effort. Something I have done for a few restricted C katas (such as the % one i linked above) is to define dummy versions of the library functions I want to ban, sharing the same name. If the user tries to call those library functions, the dummies will be called instead.
switching long for long long should be easy enough and makes sense
But declarations using external functions on the other hand sounds trickier
I probably can't just make a fancy regex disallowing most library functions, because of type aliases
so I'd have to ask the compiler or toolchain somehow
Maybe I could blacklist alot of symbols that show up in nm?
For now I've unpublished this translation cause it seems impractical to plug all the holes (like really, even sprintf is abusable).
If I could remove most libraries from the linking step it'd be easier, but I can't...
would ldd show them when they're not used?
the random tests pass numbers whose sum overflows a 64-bit integer:
10859423864060718370 + 14464185733648740227 = 6876865523999906981, but got 0
(the result is actually 21202585485961399361, which is above 2 ** 64 - 1)
<stdio.h> is pre-included for your debugging convenience.
including <stdio.h> in preloaded has no effect on the test suite: the preloaded section lives in its own separate compilation unit, and is not concatenated to the user's compilation unit. the Codewars C runner compiles code roughly as follows: cc preloaded.c solution.c tests.c
it is not very useful to forbid #include anyways, since you can just declare the functions that you need manually. for example, the kata can be cheesed like so:
the use of long / unsigned long in user-facing code on Codewars is problematic as some users are writing and debugging their solutions on 64-bit Windows, and they run into issues because long is 32-bit there while it's 64-bit on Linux, including Codewars. long long is 64-bit on both and is preferable.
there is still an issue here. because the lyrics include this single non-ASCII character, the initial code in C should specify that the expected output encoding is UTF-8. i did it in this fork, pending approval.
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
Yes, your example is invalid code and should throw an error.
A
call
uses the variablevarx
andvarx
has not been defined at the time of the call.I note that this scenario is not actually being tested.
Expurple's example is also invalid, beause there is no
changeA
variable defined.proc
parameters are not global definitions.so, I did it, but it'll break when they update clang past clang 8 for sure
I believe there is a general dislike of katas with source code restrictions among power users on Codewars (with the exception of code golf, as the byte size of the source file is something that is both easy to check and hard to fake without using techniques that would get one banned) because those restrictions are hard to enforce and require very complex test suites that are hard to maintain. Some users will come up with very clever ways of bypassing them, which means the katas have to be patched regularly, which is a maintenance hassle. This is especially true in dynamic languages such as Python and JavaScript. C is different, but has its own specific loopholes due to its low-level nature.
In some such katas it's somewhat more manageable as the there is a single thing banned (e.g. alphanumeric characters, if and '?', %, digits) that are very easy to scan for in the source code. But in the current kata many things need to be banned, which makes it more complicated.
As far as I know, checking the shared object dependencies / symbol table for anti-cheat purposes has never been done on Codewars, but I do not think it would be worth the effort. Something I have done for a few restricted C katas (such as the % one i linked above) is to define dummy versions of the library functions I want to ban, sharing the same name. If the user tries to call those library functions, the dummies will be called instead.
switching long for long long should be easy enough and makes sense
But declarations using external functions on the other hand sounds trickier
I probably can't just make a fancy regex disallowing most library functions, because of type aliases
so I'd have to ask the compiler or toolchain somehow
Maybe I could blacklist alot of symbols that show up in
nm
?For now I've unpublished this translation cause it seems impractical to plug all the holes (like really, even sprintf is abusable).
If I could remove most libraries from the linking step it'd be easier, but I can't...
would
ldd
show them when they're not used?Weak sauce
the random tests pass numbers whose sum overflows a 64-bit integer:
(the result is actually
21202585485961399361
, which is above2 ** 64 - 1
)including
<stdio.h>
in preloaded has no effect on the test suite: the preloaded section lives in its own separate compilation unit, and is not concatenated to the user's compilation unit. the Codewars C runner compiles code roughly as follows:cc preloaded.c solution.c tests.c
#include
anyways, since you can just declare the functions that you need manually. for example, the kata can be cheesed like so:long
/unsigned long
in user-facing code on Codewars is problematic as some users are writing and debugging their solutions on 64-bit Windows, and they run into issues becauselong
is 32-bit there while it's 64-bit on Linux, including Codewars.long long
is 64-bit on both and is preferable.C:
'…'
) whose encoding is not specified. It should be mentioned that the expected encoding is UTF-8;300
, as reported thereboth fixed here
there is still an issue here. because the lyrics include this single non-ASCII character, the initial code in C should specify that the expected output encoding is UTF-8. i did it in this fork, pending approval.
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.
Can't you copy/paste it from the description?
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.
fixed
Loading more items...