the input is an array of bits, so int would waste memory. bool would have been a better fit for this precise kata, yes, but unsigned char is the standard datatype for working with binary data (because it is byte-sized and because it avoids the usual caveats of bitwise operators with signed numbers)

Respectable approach for sure, but I still feel that being able to prove the answer is what you suspect it to be is also a pretty important skill (not sure if that's what you meant or not).

The real abomination is modern website and OS design and planned obsolescence enacted through willful anti-efficiency. But the 17th ret*=59; overflows unsigned long long anyway. I simply precomputed the final answers, and 24 was still overkill, and now I can see that the last third of even those few are simply wrong.

Excellent kata, approved at average vote of kyu 2!

Could it be that the Shell tests are broken???

Please when you post a question, don't post an issue... but a question.

when in fact there is a valid input.

Can you give some example: input town + result of the test.
30 people passed the Shell kata so I am quite sure that tests are not broken.

Please use spoiler flag next time. Your comment is visible from the dashboard.

Manual notification.

The easiest approach to making a value like this is to write C (or asm) code on your machine, compile it, and copy the hexdump of the function. You need to save it under the same name the function is supposed to be, and make sure you compile (or write, in case of asm code) it as Position Independent Code.
You can store it in as big as a variable you want to, but you need to get the endianness correct (Array element are stored in sequence, but a long long is stored as chars in reverse!)

The code you write gets assembled separetely from the test, so the test only knows the type of something from the type declaration.
You can write an array / single value in one file, then make a function declaration in another file. This makes the second file treat your value as a function.
The array I created is a byte code that multiplies the values (that are in two specific registers) and return the result. It doesn't matter that it is an ll array, the second file treats it as a function, so it calls it and it just works.

Nope, it works without any side effects. The str param will be copied or will be passed as an rvalue.

Correct.

@hobovski Technically you can still square whatever it is that you need to compare with the actual distance, and compare that with the squared distance. Mathematically of course it makes no difference, but for sure taking squares is faster than taking squared roots.

Then whether this is important or not for the benchmarks it's a different story.

This is an issue very specific to your personal approach (see your comment below), not a general issue. You just need to rethink how you tackle the problem. Hint: The number of depth levels should be irrelevant.